Re: intermittent resolution
131107203052 20131031203052 42006 ncep.noaa.gov. poUREStH+jGSqFvEHjgzZbsj9pZfptDDN3XucpYzlEu+KmeghLGNI1pv VG4HEWAm9uvGHxtEdOgK0vYGaSf5a4P0VEzyIoRycM1wMA8Rc7wqt9fs jA/0ir8Ke0/p9iJLX2y0UDXrQo7aMFE97X8ImdMjGQsoJBL6sYXam54X 0Q8OMMCI5nJWgr7aDWOFC2K0m43CNajDx7fIusS/tc5e1gmuEqqmP4L7 8QxuN/lnqj2W+2/DplqpuSSKJlOD3ZIAQpv/O8N25mVxQfsdbbg/vGWN yFrrIMfIPrf4RviM2ZE8kIJPfoDu/TKjQZracyIHU9e6ycaQxxGDEXmY PfQgag== ;; Received 2635 bytes from 2610:20:8000:8c00::237#53(ns-e.noaa.gov) in 311 ms > On Oct 30, 2013, at 5:24 PM, Mark Andrews wrote: > > >=20 > > IF YOU WANT HELP SPECIFY THE FAILING DOMAIN NAME. YES I AM = > SHOUTING > >=20 > > This report is like saying you have a problem with a car manufacture = > by GM. > >=20 > > Mark > >=20 > > In message , Con Wieland = > writes: > >> I recently upgraded to version: 9.8.6. I am having trouble resolving = > a .gov s > >> ite. When I reload the name server it will resolve fine for a while = > then afte > >> r an hour or two I will get a server fail. I can perform a dig +trace = > and res > >> olve but dig will fail. If I do an rndc reload it will work for some = > period o > >> f time again. I suspect negative caching but the site has a the ttl = > set to 6 > >> 0 so I would expect it to resolve again but it doesn't until a reload = > is pref > >> ormed, other sites seem to be effected but I don't know. This is a = > high visi > >> bility site. The only configuration change has been to add RPZ which = > seems to > >> be working fine.=20 > >>=20 > >> Other name servers seem to be unaffected. What am I missing? What = > else can I=20 > >> check? I can provide more details if it would be helpful. > >>=20 > >> Con Wieland > >> Office of Information Technology > >> University of California at Irvine > >> ___ > >> Please visit https://lists.isc.org/mailman/listinfo/bind-users to = > unsubscribe > >> from this list > >>=20 > >> bind-users mailing list > >> bind-users@lists.isc.org > >> https://lists.isc.org/mailman/listinfo/bind-users > > --=20 > > Mark Andrews, ISC > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: [External] Re: intermittent resolution
see > ms to be working fine. > >>>> > >>>> Other name servers seem to be unaffected. What am I missing? What else c > an I check? I can provide more details if it would be helpful. > >>> > >>> Can you tell us _what_ .gov site? Do you see the same problem with 9.9. > 4? > >>> > >>> AlanC > >>> -- > >>> Alan Clegg | +1-919-355-8851 | a...@clegg.com > >>> > >> > >> ___ > >> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscr > ibe 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 unsubscri > be 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 -- 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: Message parser reports malformed message packet
.112.36.4 h.root-servers.net. 360 IN A 128.63.2.53 i.root-servers.net. 360 IN A 192.36.148.17 j.root-servers.net. 360 IN A 192.58.128.30 k.root-servers.net. 360 IN A 193.0.14.129 l.root-servers.net. 360 IN A 198.32.64.12 ;; Query time: 368 msec ;; SERVER: 201.76.40.2#53(201.76.40.2) ;; WHEN: Tue Nov 05 07:56:01 EST 2013 ;; MSG SIZE rcvd: 512 In message , =?iso-8859-1?B?RuFiaW 8gR29tZXM=?= writes: > Hi, > > I'm having issues trying to resolve www.sondait.tasker.com.br. The > result from dig +trace is as follows: > > > > # dig www.sondait.tasker.com.br +trace > > ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.17.rc1.el6_4.6 <<>> > www.sondait.tasker.com.br +trace > ;; global options: +cmd > . 516836 IN NS c.root-servers.net. > . 516836 IN NS a.root-servers.net. > . 516836 IN NS f.root-servers.net. > . 516836 IN NS i.root-servers.net. > . 516836 IN NS j.root-servers.net. > . 516836 IN NS b.root-servers.net. > . 516836 IN NS h.root-servers.net. > . 516836 IN NS k.root-servers.net. > . 516836 IN NS m.root-servers.net. > . 516836 IN NS l.root-servers.net. > . 516836 IN NS d.root-servers.net. > . 516836 IN NS e.root-servers.net. > . 516836 IN NS g.root-servers.net. > ;; Received 512 bytes from 172.31.1.254#53(172.31.1.254) in 13 ms > > br. 172800 IN NS a.dns.br. > br. 172800 IN NS b.dns.br. > br. 172800 IN NS c.dns.br. > br. 172800 IN NS d.dns.br. > br. 172800 IN NS e.dns.br. > br. 172800 IN NS f.dns.br. > ;; Received 323 bytes from 192.203.230.10#53(192.203.230.10) in 139 ms > > tasker.com.br. 86400 IN NS ns1.locaweb.com.br. > tasker.com.br. 86400 IN NS ns2.locaweb.com.br. > tasker.com.br. 86400 IN NS ns3.locaweb.com.br. > ;; Received 153 bytes from 200.160.0.10#53(200.160.0.10) in 34 ms > > ;; Warning: Message parser reports malformed message packet. > ;; Truncated, retrying in TCP mode. > ;; Connection to 201.76.40.2#53(201.76.40.2) for > www.sondait.tasker.com.br failed: connection refused. > ;; Connection to 187.45.246.2#53(187.45.246.2) for > www.sondait.tasker.com.br failed: connection refused. > ;; Connection to 189.126.108.2#53(189.126.108.2) for > www.sondait.tasker.com.br failed: connection refused. > > > I don't know where to start to solve this issue. Using my Internet > provider's DNS I got a positive answer. > > Could you please help me solve this issue? > > > Thanks in advance. > _______ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to > unsubscribe from this list > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Message parser reports malformed message packet
gt; > > > ;; QUESTION SECTION: > > ;www.sondait.tasker.com.br. IN A > > > > ;; ANSWER SECTION: > > www.sondait.tasker.com.br. 3600 IN CNAME trial-1910070769.sa-east-1.elb.ama > zonaws.com. > > > > ;; AUTHORITY SECTION: > > . 518400 IN NS a.root-servers.net. > > . 518400 IN NS b.root-servers.net. > > . 518400 IN NS c.root-servers.net. > > . 518400 IN NS d.root-servers.net. > > . 518400 IN NS e.root-servers.net. > > . 518400 IN NS f.root-servers.net. > > . 518400 IN NS g.root-servers.net. > > . 518400 IN NS h.root-servers.net. > > . 518400 IN NS i.root-servers.net. > > . 518400 IN NS j.root-servers.net. > > . 518400 IN NS k.root-servers.net. > > . 518400 IN NS l.root-servers.net. > > . 518400 IN NS m.root-servers.net. > > > > ;; ADDITIONAL SECTION: > > a.root-servers.net. 360 IN A 198.41.0.4 > > b.root-servers.net. 360 IN A 192.228.79.201 > > c.root-servers.net. 360 IN A 192.33.4.12 > > d.root-servers.net. 360 IN A 128.8.10.90 > > e.root-servers.net. 360 IN A 192.203.230.10 > > f.root-servers.net. 360 IN A 192.5.5.241 > > g.root-servers.net. 360 IN A 192.112.36.4 > > h.root-servers.net. 360 IN A 128.63.2.53 > > i.root-servers.net. 360 IN A 192.36.148.17 > > j.root-servers.net. 360 IN A 192.58.128.30 > > k.root-servers.net. 360 IN A 193.0.14.129 > > l.root-servers.net. 360 IN A 198.32.64.12 > > > > ;; Query time: 368 msec > > ;; SERVER: 201.76.40.2#53(201.76.40.2) > > ;; WHEN: Tue Nov 05 07:56:01 EST 2013 > > ;; MSG SIZE rcvd: 512 > > > > In message , =?iso-8859-1?B?Ru > FiaW > > 8gR29tZXM=?= writes: > >> Hi, > >> > >> I'm having issues trying to resolve www.sondait.tasker.com.br. The > >> result from dig +trace is as follows: > >> > >> > >> > >> # dig www.sondait.tasker.com.br +trace > >> > >> ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.17.rc1.el6_4.6 <<>> > >> www.sondait.tasker.com.br +trace > >> ;; global options: +cmd > >> . 516836 IN NS c.root-servers.net. > >> . 516836 IN NS a.root-servers.net. > >> . 516836 IN NS f.root-servers.net. > >> . 516836 IN NS i.root-servers.net. > >> . 516836 IN NS j.root-servers.net. > >> . 516836 IN NS b.root-servers.net. > >> . 516836 IN NS h.root-servers.net. > >> . 516836 IN NS k.root-servers.net. > >> . 516836 IN NS m.root-servers.net. > >> . 516836 IN NS l.root-servers.net. > >> . 516836 IN NS d.root-servers.net. > >> . 516836 IN NS e.root-servers.net. > >> . 516836 IN NS g.root-servers.net. > >> ;; Received 512 bytes from 172.31.1.254#53(172.31.1.254) in 13 ms > >> > >> br. 172800 IN NS a.dns.br. > >> br. 172800 IN NS b.dns.br. > >> br. 172800 IN NS c.dns.br. > >> br. 172800 IN NS d.dns.br. > >> br. 172800 IN NS e.dns.br. > >> br. 172800 IN NS f.dns.br. > >> ;; Received 323 bytes from 192.203.230.10#53(192.203.230.10) in 139 ms > >> > >> tasker.com.br. 86400 IN NS ns1.locaweb.com.br. > >> tasker.com.br. 86400 IN NS ns2.locaweb.com.br. > >> tasker.com.br. 86400 IN NS ns3.locaweb.com.br. > >> ;; Received 153 bytes from 200.160.0.10#53(200.160.0.10) in 34 ms > >> > >> ;; Warning: Message parser reports malformed message packet. > >> ;; Truncated, retrying in TCP mode. > >> ;; Connection to 201.76.40.2#53(201.76.40.2) for > >> www.sondait.tasker.com.br failed: connection refused. > >> ;; Connection to 187.45.246.2#53(187.45.246.2) for > >> www.sondait.tasker.com.br failed: connection refused. > >> ;; Connection to 189.126.108.2#53(189.126.108.2) for > >> www.sondait.tasker.com.br failed: connection refused. > >> > >> > >> I don't know where to start to solve this issue. Using my Internet > >> provider's DNS I got a positive answer. > >> > >> Could you please help me solve this issue? > >> > >> > >> Thanks in advance. > >> ___ > >> 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 -- 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: Message parser reports malformed message packet
In message <20131105121905.ga22...@fantomas.sk>, Matus UHLAR - fantomas writes: > On 05.11.13 10:02, F=E1bio Gomes wrote: > >I'm gonna try to contact the domain owners as well, but I noticed my > > enterprise DNS can get a correct answer for that domain. Is there any way > > I can force different response from localweb servers until I got this > > permanently fixed? Like force UDP packet sizes or disable EDNS for that > > domain? Could you also, please, share the tcpdump line you used to get > > that package details? > > seems their nameservers are working correctly now, with or without TCP (even > with EDNS0) No they are not. EDNS hides the problem. If you use plain DNS the problem is still visible. Mark ;; Warning: Message parser reports malformed message packet. ;; Truncated, retrying in TCP mode. ; <<>> DiG 9.10.0a1 <<>> www.sondait.tasker.com.br +noedns @201.76.40.2 +norec ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45899 ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL: 13 ;; QUESTION SECTION: ;www.sondait.tasker.com.br. IN A ;; ANSWER SECTION: www.sondait.tasker.com.br. 3600 IN CNAME trial-1910070769.sa-east-1.elb.amazonaws.com. ;; AUTHORITY SECTION: . 518400 IN NS a.root-servers.net. . 518400 IN NS b.root-servers.net. . 518400 IN NS c.root-servers.net. . 518400 IN NS d.root-servers.net. . 518400 IN NS e.root-servers.net. . 518400 IN NS f.root-servers.net. . 518400 IN NS g.root-servers.net. . 518400 IN NS h.root-servers.net. . 518400 IN NS i.root-servers.net. . 518400 IN NS j.root-servers.net. . 518400 IN NS k.root-servers.net. . 518400 IN NS l.root-servers.net. . 518400 IN NS m.root-servers.net. ;; ADDITIONAL SECTION: a.root-servers.net. 360 IN A 198.41.0.4 b.root-servers.net. 360 IN A 192.228.79.201 c.root-servers.net. 360 IN A 192.33.4.12 d.root-servers.net. 360 IN A 128.8.10.90 e.root-servers.net. 360 IN A 192.203.230.10 f.root-servers.net. 360 IN A 192.5.5.241 g.root-servers.net. 360 IN A 192.112.36.4 h.root-servers.net. 360 IN A 128.63.2.53 i.root-servers.net. 360 IN A 192.36.148.17 j.root-servers.net. 360 IN A 192.58.128.30 k.root-servers.net. 360 IN A 193.0.14.129 l.root-servers.net. 360 IN A 198.32.64.12 m.root-servers.net. 360 IN A 202.12.27.33 ;; Query time: 819 msec ;; SERVER: 201.76.40.2#53(201.76.40.2) ;; WHEN: Wed Nov 06 00:03:39 EST 2013 ;; MSG SIZE rcvd: 520 > -- = > > Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ > Warning: I wish NOT to receive e-mail advertising to this address. > Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. > I'm not interested in your website anymore. > If you need cookies, bake them yourself. > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscri= > be from this list > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Recursive DNS server cannot resolve the reverse zone records from my IPv6 private network
In message <527a8ac4.3010...@adminlinux.com.br>, Listas writes: > > Hi, > > I'm enabling IPv6 dual stack in my network and my Bind authoritative > servers are working perfectly with the ip6.arpa zones. > > But my Recursive DNS server cannot resolve the reverse zone records from > my private network. I tried to make a setup similar to what I do for my > private network (IPv4 RFC1918) 10.0.0.0, but no success. > > Can anyone help me? > > The configuration of my recursive server is here: > http://adminlinux.com.br/recursive-bind.conf Firstly you are using the wrong addresses range. You should be using FD00::/8 for locally assigned addresses. FC00::/8 is reserved for centrally assigned local addresses and there isn't yet a registry to perform those assignments so no one should be using them. Secondly change "5.a.8.3.2.e.3.e.0.0.c.f.ip6.arpa" into a slave zone and transfer the contents from the other server. Add this server as a nameserver to the zone or configure the master to send this server notify messages when the zone changes. Presumably the existing master zone is just a empty zone which is why you got the NXDOMAIN. Mark -- 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: dns not resolving
If you have "check-mx fail;" in named.conf then the zone will not load and
you will get SERVFAIL. The default is "check-mx warn;".
12-Nov-2013 07:40:07.546 zone jeffdiss.org/IN: jeffdiss.org/MX
'mail.jeffdiss.org' has no address records (A or )
12-Nov-2013 07:40:07.546 zone jeffdiss.org/IN: not loaded due to errors.
I would check the log files on the server and address any errors/warnings
reported then try again. Also be explicit when you want to check a master
server and use @server to make sure you are talking to the machine you
think you are and +norec so referrals are returned.
Additionally you should show the relevent parts of named.conf when asking
for help as the contents affect how named treats the zone.
options {
pid-file none;
check-mx fail;
};
zone "jeffdiss.org" {
type master;
file "junk";
};
Mark
In message <8b04639343ffed47b61063517bd9b1f1296b5...@uvuexchmb1.ad.uvu.edu>,
"S. Jeff Cold" writes:
>
> I have two DNS servers both running Debian Linux 7.2.0, BIND 9.8.4 in a
> private LAN. I set up an unregistered domain to see how things would
> run. When I run dig on the domain just to see if it will resolve, I get
> this error:
>
> ; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> jeffdiss.org
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 22495
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
>
> ;; QUESTION SECTION:
> ;jeffdiss.org.INA
>
> ;; Query time: 0 msec
> ;; SERVER: 192.168.1.50#53(192.168.1.50)
> ;; WHEN: Mon Nov 11 10:05:10 2013
> ;; MSG SIZE rcvd: 30
>
> BIND's configuration file is :
>
> $TTL3600
> $ORIGIN jeffdiss.org.
> ; Start of Authority record defining the key characteristics of the zone
> (domain)
> @INSOAserver1.jeffdiss.org. zonemaster.jeffdiss.org. (
> 2013110701; serial, todays date + serial num
> 7200; refresh, seconds
> 540; retry, seconds
> 604800; expire, seconds
> 86400 ; minimum, seconds
> )
>
> ; name servers Resources Records (RR) for the domain
> INNSserver1.jeffdiss.org.
>
> ; the second name server
> INNSserver2.jeffdiss.org.
>
> ; mail server Resource Records (RR) for the domain
>3wINMX 10mail.jeffdiss.org.
>
> ; domain hosts includes NS and MX records defined above plus any others
> required
> server1INA192.168.1.50
> server2INA192.168.1.51
> www IN A192.168.1.51
>
> This seems simple enough. I'm running dig from the primary DNS server
> itself and I'm thinking I should be able to get an answer for
> jeffdiss.org. Can someone point me in the right direction?
>
> Jeff
>
>
--
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: Can I have Inbound load balancing achieved with below settings
In message , Joseph S D Yao writes: > On 2013-11-13 00:16, Manish Rane wrote: > ... > > 6.Assume if ISP1 goes down, client coming on ISP1 would never be able > > to reach; hence as per DNS protocol will try for another link and > > come > > on ISP2 and then probably get an IP address of Link 2 i.e. 2.2.2.2. > ... > > > I'm not sure about your DNS setup, because I didn't understand how you > described it. But that doesn't matter. > > Even if you 100% properly did what you intended to do, it breaks down > at step 6. The DNS protocol definitions only go as far as saying what > your BIND DNS server will return. Importantly (for this answer), it > does NOT say (a) what a remote user's caching/resolving name server will > actually do with your responses, or (b) what the actual application will > do with your responses. > > If the application is an SMTP server or another DNS server then, yes, > BY THE DEFINITION OF THAT PROTOCOL, it will try again for another > server. RFC 1123 (October 1989) applies to all applications on all hosts. Note "SHOULD" and "until". 2.3 Applications on Multihomed hosts When the remote host is multihomed, the name-to-address translation will return a list of alternative IP addresses. As specified in Section 6.1.3.4, this list should be in order of decreasing preference. Application protocol implementations SHOULD be prepared to try multiple addresses from the list until success is obtained. More specific requirements for SMTP are given in Section 5.3.4. When the local host is multihomed, a UDP-based request/response application SHOULD send the response with an IP source address that is the same as the specific destination address of the UDP request datagram. The "specific destination address" is defined in the "IP Addressing" section of the companion RFC [INTRO:1]. Similarly, a server application that opens multiple TCP connections to the same client SHOULD use the same local IP address for all. > If the application is a Web browser - which is likely, given that you > mention port 80, presumably TCP - then it will only look at one of the > two IP addresses [for almost all currently available Web browsers]. If > it gets a bad one, it will return the user an error. Because that is > how THAT protocol is defined. Most protocols are not defined to re-try > different servers. No, there is no such requirement. The browsers are just BROKEN if they don't try all the offered addresses. All browsers we were written after RFC 1123 was published. > What you are trying to do is what the F5 BigIP GTM does - only return > the IP address for a known-working site. There's a reason that F5 can > sell those boxes - they work where doing this in pure DNS does not. > > > Joe Yao > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Can I have Inbound load balancing achieved with below settings
In message , Barry Mar golin writes: > In article , > Mark Andrews wrote: > > > No, there is no such requirement. The browsers are just BROKEN if > > they don't try all the offered addresses. All browsers we were > > written after RFC 1123 was published. > > That attitude should probably be moderated when interactive applications > are involved. It means that users will have to wait for an arbitrary > number of timeouts before the browser can give them an error message. And there is no requirement to wait 30 seconds for the next connection attempt. If in the 80's if it took more than 1 or 2 seconds to connect you could assume it wasn't going to succeed and be right 99.99% of the time. With happy eyeballs the second and subsequent connection attempts start in less than a second (~100-200ms) after the previous one and you abandon redundant successful connections. While happy eyeballs was looking at IPv4/IPv6 that is only a special case of multi-homed servers. > The requirement is stated as a SHOULD, not a MUST. This gives latitude > to the application designer to trade off reliability and usability. So rather than doing staggered parallel connects which would have given them reliability and usability they decided to throw away reliability. Non blocking connects have existed since before the first web browser was written. > -- > Barry Margolin > Arlington, MA > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- 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: Can I have Inbound load balancing achieved with below settings
In message <661ca5ab225cad04bdcc3831c6964...@tux.org>, Joseph S D Yao writes: > On 2013-11-13 16:44, Mark Andrews wrote: > ... > > RFC 1123 (October 1989) applies to all applications on all hosts. > > Note "SHOULD" and "until". > ... > > > Mark, I've always read "SHOULD" here as more of a plaintive hope than > anything else. People have certainly felt free to ignore it. Yes, that > makes their software "broken" if you are reading "SHOULD" as almost a > "MUST". Which is how it is defined in the RFC. *"SHOULD" This word or the adjective "RECOMMENDED" means that there may exist valid reasons in particular circumstances to ignore this item, but the full implications should be understood and the case carefully weighed before choosing a different course. We have "MAY" for the plaintive hope case. *"MAY" This word or the adjective "OPTIONAL" means that this item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because it enhances the product, for example; another vendor may omit the same item. I just wish vendors were required to publish the analysis that lead them to not follow a SHOULD. I'd love to hear NETGEAR's analysis of why their DNS proxy doesn't talk TCP in the router I have here at home and see if it passes the laugh test. Mark -- 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: Listen queue overflow
In message , vinny_abe...@dell.com writes: > Hi Everyone, > > I recently had a recursive server running BIND 9.9.4 on FreeBSD 9.2 > appear to wedge and stop responding to clients. I had a flurry of these > errors on the console: > > sonewconn: pcb 0xfe007211d930: Listen queue overflow: 16 already in > queue awaiting acceptance > > I couldn't trace that directly back to the named process by the time I > looked at it, but I suspect that's what it was since it's really the only > thing this machine is used for and it stopped working. It seems to have > oddly become unstuck when I logged into the machine and started looking > around. I never restarted named. Everything else on the server was > running normally from what I could tell and no other errors existed that > I could find. Unfortunately my logs rolled over too fast to check if > named had logged anything else interesting. > > From what I've found in googling, this is an OS level error stating the > process isn't accepting new TCP connections and it's an application > fault. I've only ever seen this on this particular machine, and just this > once. My other recursive servers are running older versions of FreeBSD. Or it's just a plain DoS attack. For any service it is possible to send tcp connection requests faster than the service can handle it. > Has anyone come across this before and know how to prevent or correct > this properly? You can tune tcp-listen-queue in named.conf. The current default is 10. > Thanks! > > -Vinny > -- 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: Non-recursive nameserver response to DS request
In message , Chris Tho mpson writes: > A user here was confused by the fact that > > dig -t DS cam.ac.uk @authdns0.csx.cam.ac.uk > > gives an (authoritative!) "nodata" response. (Well actually he was using > "host" rather than "dig", but the principle is the same.) > > The server is authoritative-only and gives REFUSED when queried about > other zones, so my first thought was that it ought to have deduced > that the DS record for cam.ac.uk lives in ac.uk, and that is not one > of the zones it is authoritative for, and so REFUSED would be the right > response. > > If the nameserver is authoritative for both parent and child, and > the DS record for the child is requested, it correctly returns the > one from the parent zone. Well, obviously this must work, as the > situation is common. > > So is this a BIND bug? Or is it somehow allowed by small print in > the RFCs somewhere? RFC 4035 Section B.8. DS Child Zone No Data Error > [Adding +dnssec provides a response that proves there is no DS > record for cam.ac.uk in the zone cam.ac.uk, which of course is true.] > > -- > Chris Thompson > Email: c...@cam.ac.uk > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Allow recursion for esternal resources in a authoritative zone on a "not open" dns server
In message , "Chiesa Stefano" writes: > Hello all. > > I have a "closed" bind dns server. It answers only to queries related to > zones it is authoritative for (a normal behaviour... right?). > I have dns zones that contain cname that points to hostnames in domains > not managed by that server. > So it won't resolve that names returning the cname to the client. This is correct operation. Recursive/iterative servers talking to it do not need your server to resolve the target of the cname. They will go ask the nameservers for the target of the cname themselves then combine the two answers and return that to the caller. Stub resolvers need to talk to a recursive server so it can do this work on their behalf. > I'd like to know if there is a way to tell to BIND "if the external > resource is in a domain managed by you, resolve (do recourse)" > > Do you know if it is possible? No. > Thanks in advance, > Stefano. > > > Stefano Chiesa > Wolters Kluwer Italia > Network Specialist > Strada 1, Palazzo F6 > 20090 Milanofiori Assago (Mi) - Italia > Phone +39 0282476279 (20279 Voip) > Fax +39 0282476815 > > > > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Allow recursion for esternal resources in a authoritative zone on a "not open" dns server
In message , Barry Margolin writes: > In article , > Mark Andrews wrote: > > > In message > > , > > "Chiesa Stefano" writes: > > > I'd like to know if there is a way to tell to BIND "if the external > > > resource is in a domain managed by you, resolve (do recourse)" > > > > > > Do you know if it is possible? > > > > No. > > If the server is authoritative for both the CNAME and the target of the > CNAME, no recursion should be necessary -- the target is already in its > memory. Doesn't the server normally fill in the whole CNAME chain in > this case? The targets of the CNAME records are not on the machine as per the original description of the problem. "I have dns zones that contain cname that points to hostnames in domains not managed by that server." Mark > > -- > Barry Margolin > Arlington, MA > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- 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: Recursive DNS server cannot resolve the reverse zone records from my IPv6 private network
In message <528b9d20.7020...@adminlinux.com.br>, Listas writes:
> Hi ! Thank you for help.
>
> Sorry, I made a mistake in time to hide the addresses. I'm using
> FD00::/8 in my network. My conf was
> updated:http://adminlinux.com.br/recursive-bind.conf
Don't update. Re-create it from scratch showing the *entire* zone
content and both the master and recursive server configurations.
At the moment is is a mis-mash of old and new data and is internally
inconsistent. It is also not complete enough.
> My system has three types of DNS server: master, slave and recursion.
> The zone "5.a.8.3.2.e.3.e.0.0.cfip6.arpa" is working well in master and
> slave servers (authoritative server for the zone). Queries to 127.0.0.1
> and ::1 are being answered correctly on these servers.
>
> My file /etc/bind/db.fd really was wrong and I corrected. He just has to
> correctly point the authoritative server for the zone.
>
> But my recursion servers are not sending the questions to
> ns1.mydomain.com and ns2.mydomain.com.
>
> In my view the reverse resolution of the network fd00 :: / 8 should be
> occurring as well as occurs with the network 10.0.0.0 / 8. Because the
> configuration is equivalent.
> Can anyone see any point that I'm letting out?
>
> Thanks for help.
> --
> Thiago Henrique
> www.adminlinux.com.br
>
>
> On 07-11-2013 06:56, Niall O'Reilly wrote:
> > On 6 Nov 2013, at 18:30, Listas wrote:
> >
> >> ;; QUESTION SECTION:
> >> ;f.1.4.2.0.0.0.0.0.0.0.0.0.0.0.0.7.0.0.0.5.a.8.3.2.e.3.e.0.0.c.f.ip6.arpa.
> >> IN PTR
> > And placed the following (and more) data at
> > http://adminlinux.com.br/recursive-bind.conf
> >
> > /etc/bind/named.conf.local-ip6:
> >
> > zone "5.a.8.3.2.e.3.e.0.0.c.f.ip6.arpa" IN {
> >type master;
> >file "/etc/bind/db.fc";
> > };
> >
> >
> > /etc/bind/db.fc:
> > $TTL 86400 ; Minimum TTL of 1 day.
> >
> > @ IN SOA ns1.mydomain.com. dnsmasters.mydomain.com. (
> >1 ; Serial.
> >10800 ; Refresh after 3 hours.
> >3600; Retry after 1 hour.
> >604800 ; Expire after 1 week.
> >86400 ) ; Minimum TTL of 1 day.
> >
> > IN NS ns1.mydomain.com.
> > IN NS ns2.mydomain.com.
> >
> > 10 IN NS ns3.mydomain.com.
> > IN NS ns4.mydomain.com.
> >
> > 12 IN NS ns5.mydomain.com.
> > IN NS ns6.mydomain.com.
> >
> > 16 IN NS ns7.mydomain.com.
> > IN NS ns8.mydomain.com.
> >
> > 20 IN NS ns9.mydomain.com.
> > IN NS ns10.mydomain.com.
> >
> >
> >
> > The zone file you've chosen to show us has records only for the
> > following names:
> >
> > 5.a.8.3.2.e.3.e.0.0.c.f.ip6.arpa.
> > 10.5.a.8.3.2.e.3.e.0.0.c.f.ip6.arpa.
> > 12.5.a.8.3.2.e.3.e.0.0.c.f.ip6.arpa.
> > 16.5.a.8.3.2.e.3.e.0.0.c.f.ip6.arpa.
> > 20.5.a.8.3.2.e.3.e.0.0.c.f.ip6.arpa.
> >
> > None of these matches the target of your query, so the result is
> > NXDOMAIN.
> > Anything else would be strange.
> >
> > If you need the server to return some other result for this query, you
> > must place the corresponding record(s) in the zone file you're using.
> >
> > Best regards,
> > Niall O'Reilly
> >
>
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: dig 9.9.[234] unable to do zone transfers from MS windows Domain Controllers
In message <1f415f5e-7623-4e44--0bd394442...@gmail.com>, Cipher Nix writes: > Thanks for the quick response. "dig +noedns" did it. Thank you. It still should not have resulted in a "extra input data". It would be useful to see the hex dump of the dns message that triggered the "extra input data" message. Mark > > On Nov 20, 2013, at 22:09, Evan Hunt wrote: > > > >> On Wed, Nov 20, 2013 at 09:46:40PM -0500, cypher Nix wrote: > >> Bind 9.9.x is able to perform zone transfers from the Windows DC > >> without any issue. Performing a named-checkzone against the zone file > >> with bind 9.9.4 and bind 9.9.2 returns no errors. It looks like the > >> issue is just with DIG 9.9.2 and 9.9.4 (possibly other versions of dig > >> 9.9). > >> > >> Has anyone ran into a similar issue? Any help would be greatly appreciated. > > > > BIND 9.9 turns on EDNS(0) by default. Try it with "dig +noedns" -- if > > it works, then that was the problem. > > > > -- > > Evan Hunt -- e...@isc.org > > Internet Systems Consortium, Inc. > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: any news/info re: RPZ2+RRL patches for bind 9.9.4-P1?
In message <1385060190.20266.50452509.48b1a...@webmail.messagingengine.com>, jen...@promessage.com writes: > On Thu, Nov 21, 2013, at 10:38 AM, /dev/rob0 wrote: > > RRL is included in 9.9.4 already. Deployed and working here. > > as specified @ > > http://ss.vix.su/~vjs/rrlrpz.html > > ... > BIND9 9.9.4 > file rpz2+rl-9.9.4.patch, version 9.9.4-rpz2+rl.13269.14 > Version 9.9.4 includes RRL with ./configure --enable-rrl so this > patch only affects RPZ. > ... > > So, that's simply a naming issue. > > IIUC, rpz2 != rpz. > > I'd applied "rpz2+rl-9.9.4.patch" to 9.9.4; with success. > > So, now, I'm asking about the name- and functionally-equivalent > "rpz2+rl-9.9.4-P1.patch" for the bind 9.9.4-P1 release. Did you try applying rpz2+rl-9.9.4-P1.patch to 9.9.4-P1? Apart from the version file it should apply cleanly and you can ignore the version file or patch it by hand if you want. I would append "-rpz2+rl.13269.14" to "RELEASEVER=1" to give "RELEASEVER=1-rpz2+rl.13269.14" which results in a full version string of "9.9.4-P1-rpz2+rl.13269.14". > JenL > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: dig 9.9.[234] unable to do zone transfers from MS windows Domain Controllers
In message <528ec4db.6060...@hpl.hp.com>, Andris Kalnozols writes: > Hi, Mark. > > I've also seen the same problem which occurs with AXFR queries > to both Windows server 2003 and 2012: > > Win2003 > --- > > ;; Got bad packet: extra input data > > 115 bytes > > e9 f3 80 80 00 01 00 01 00 00 00 00 04 6c 61 62 .lab > > 73 03 68 70 6c 02 68 70 03 63 6f 6d 00 00 fc 00 s.hpl.hp.com > > 01 09 5f 6b 65 72 62 65 72 6f 73 04 5f 74 63 70 .._kerberos._tcp > > 02 62 61 06 5f 73 69 74 65 73 02 64 63 06 5f 6d .ba._sites.dc._m > > 73 64 63 73 c0 0c 00 21 00 01 00 00 02 58 00 23 sdcs...!.X.# > > 00 00 00 64 00 58 0b 73 75 70 70 6f 72 74 2d 62 ...d.X.support-b > > 72 31 04 6c 61 62 73 03 68 70 6c 02 05 00 00 00 r1.labs.hpl. > > 00 00 00 ... Which looks like the SRV record is corrupted. There are 4 extra zero octets at the end after the domain name finished. Note the space is correct for a record ending in .hp.com. > Win2012 > --- > > ;; Got bad packet: extra input data > > 118 bytes > > 91 7d 80 80 00 01 00 01 00 00 00 00 05 69 6c 61 .}...ila > > 62 73 03 68 70 6c 02 68 70 03 63 6f 6d 00 00 fc bs.hpl.hp.com... > > 00 01 09 5f 6b 65 72 62 65 72 6f 73 04 5f 74 63 ..._kerberos._tc > > 70 02 62 61 06 5f 73 69 74 65 73 02 64 63 06 5f p.ba._sites.dc._ > > 6d 73 64 63 73 c0 0c 00 21 00 01 00 00 02 58 00 msdcs...!.X. > > 25 00 00 00 64 00 58 0c 69 73 75 70 70 6f 72 74 %...d.X.isupport > > 2d 70 61 35 05 69 6c 61 62 73 03 05 00 00 00 00 -pa5.ilabs.. > > 00 00 00 6f 6d 00...om. Again the end of the SRV record is corrupted. Similarly the space is correct for a record ending in .hpl.hp.com. One should be able to see the corruption in a packet trace to confirm that it isn't a bug in dig. Mark > -- > Andris > > > Mark Andrews wrote: > > > > In message <1f415f5e-7623-4e44--0bd394442...@gmail.com>, Cipher Nix wri > tes: > >> Thanks for the quick response. "dig +noedns" did it. Thank you. > > > > It still should not have resulted in a "extra input data". > > > > It would be useful to see the hex dump of the dns message > > that triggered the "extra input data" message. > > > > Mark > > > >>> On Nov 20, 2013, at 22:09, Evan Hunt wrote: > >>> > >>>> On Wed, Nov 20, 2013 at 09:46:40PM -0500, cypher Nix wrote: > >>>> Bind 9.9.x is able to perform zone transfers from the Windows DC > >>>> without any issue. Performing a named-checkzone against the zone file > >>>> with bind 9.9.4 and bind 9.9.2 returns no errors. It looks like the > >>>> issue is just with DIG 9.9.2 and 9.9.4 (possibly other versions of dig > >>>> 9.9). > >>>> > >>>> Has anyone ran into a similar issue? Any help would be greatly appreciat > ed. > >>> > >>> BIND 9.9 turns on EDNS(0) by default. Try it with "dig +noedns" -- if > >>> it works, then that was the problem. > >>> > >>> -- > >>> Evan Hunt -- e...@isc.org > >>> Internet Systems Consortium, Inc. > >> ___ > >> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscr > ibe 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 -- 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: any news/info re: RPZ2+RRL patches for bind 9.9.4-P1?
In message <1385152907.15717.50929393.189b3...@webmail.messagingengine.com>, je n...@promessage.com writes: > Hi Mark, > > On Thu, Nov 21, 2013, at 06:14 PM, Mark Andrews wrote: > > Did you try applying rpz2+rl-9.9.4-P1.patch to 9.9.4-P1? > > No, not yet. Having had bad luck with applying the wrong version patch > in the past, I've been waiting for an 'official' update. The -P's are minimal changes which just cover one or two issues unlike maintenance releases which can address a hundred issues. > > Apart from the version file it should apply cleanly and > > you can ignore the version file or patch it by hand if you > > want. I would append "-rpz2+rl.13269.14" to "RELEASEVER=1" > > to give "RELEASEVER=1-rpz2+rl.13269.14" which results in > > a full version string of "9.9.4-P1-rpz2+rl.13269.14". > > Noted as an option. Thanks! > > Given that there's no response/info at all from that project either > here, at their site, on their own mailing list, or via email, as much as > it's useful/helpful functionality, I'm wondering whether it's wiser to > just get rid of it from production. rpz2 code is itegrated into BIND 9.10. > Adding supported 3rd-party functionality to Bind is enough of a hack for > mere mortals -- adding unsupported/dead code sounds like a really bad > idea. It isn't dead. Generating a new patch just isn't a high priority item for Vernon. > JenL -- 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: script - automatic change A record
In message
, =?UTF-8?B?UGF3ZcWCIENoLg==?= writes:
> Hi list,
>
> I would like to write script that change two entry in my zone file: SOA and
> A record.
>
> I have 2 web site: mail site site1.tld and backup site site2.tld. Script
> should monitor site1.tld and when site is unavailable it should change A
> record in zone file to indicate to site2.tld. If site1.tld is available
> again then A record should indicate to it.
> Script should change SOA serial number.
>
> Please help with writing a script.
>
> pch0317
>
#!/bin/sh
while :
do
if ping -c 5 -t 5 1.2.3.4
then
nsupdate << EOF
update del host.example.net A
update add host.example.net 30 A 1.2.3.4
send
EOF
elif ping -c 5 -t 5 1.2.3.5
nsupdate << EOF
update del host.example.net A
update add host.example.net 30 A 1.2.3.5
send
EOF
else
nsupdate << EOF
update del host.example.net A
update add host.example.net 30 A 1.2.3.4
update add host.example.net 30 A 1.2.3.5
send
EOF
fi
sleep 60
done
--
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: Forward zone giving SERVFAIL
In message <000701ceebe9$cf91f6c0$6eb5e440$@JAMMConsulting.com>, "Neil
Aggarwal" writes:
> Hello:
>
> I set up a forward zone in the internal view of my named.conf:
>
> view internal {
> match-clients {
> 127.0.0.1;
> };
> recursion yes;
> allow-query-cache { any; };
> zone "dnsbl" {
> type forward;
> forwarders {
> 127.0.0.1 port 54;
> };
> forward only;
> };
> };
>
> When I run dig against the forward zone:
> dig -p 54 @127.0.0.1 2.0.0.127.zen.dnsbl
>
> It gives me the expected output:
> ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.17.rc1.el6_4.6 <<>> -p 54 @127.0.0.1
> 2.0.0.127.zen.dnsbl
> ; (1 server found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57571
> ;; flags: qr aa rd; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0
> ;; WARNING: recursion requested but not available
>
> ;; QUESTION SECTION:
> ;2.0.0.127.zen.dnsbl. IN A
>
> ;; ANSWER SECTION:
> 2.0.0.127.zen.dnsbl.300 IN A 127.0.0.2
> 2.0.0.127.zen.dnsbl.300 IN A 127.0.0.10
> 2.0.0.127.zen.dnsbl.300 IN A 127.0.0.4
>
> ;; Query time: 1 msec
> ;; SERVER: 127.0.0.1#54(127.0.0.1)
> ;; WHEN: Wed Nov 27 21:24:45 2013
> ;; MSG SIZE rcvd: 85
>
> But, when I run dig against bind:
> dig -p 53 @127.0.0.1 2.0.0.127.zen.dnsbl
>
> I get a SERVFAIL response:
> ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.17.rc1.el6_4.6 <<>> -p 53 @127.0.0.1
> 2.0.0.127.zen.dnsbl
> ; (1 server found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 46895
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
>
> ;; QUESTION SECTION:
> ;2.0.0.127.zen.dnsbl. IN A
>
> ;; Query time: 144 msec
> ;; SERVER: 127.0.0.1#53(127.0.0.1)
> ;; WHEN: Wed Nov 27 21:25:50 2013
> ;; MSG SIZE rcvd: 37
>
> Taking a look at /var/named/data/named.run, I see these lines:
> error (chase DS servers) resolving 'zen.dnsbl/DS/IN': 127.0.0.1#54
> error (unexpected RCODE REFUSED) resolving 'dnsbl/NS/IN': 127.0.0.1#54
> error (no valid DS) resolving '2.0.0.127.zen.dnsbl/A/IN': 127.0.0.1#54
>
> I am not sure what to make of this.
You have DNSSEC enabled and the root zone is signed in a way that
prevents the addition of rougue TLDs which 'dnsbl' is. This is a
good thing with ICANN adding lots of new TLDs.
In addition to that the alternate nameserver on port 54 doesn't
handle NS queries. Nameserver developers shouldn't assume that the
only queries that will be made to a nameserver will be A queries.
These days you have A and for addresses as well as NS, DS and
DNSKEY queries for DNSSEC. Then add in TLSA queries for DANE and
as browsers check for HTTPS support. The list of different query
types that regularly appear continues to grow. Nameserver should
expect the unexpected. It really isn't any harder to send a NODATA
response rather than a REFUSED.
I suggest that you report this to the black list and nameserver
vendors. Squatting on TLD's is a no-no. If they want a TLD for
their service they should pony up the money otherwise move the name
into namespace they control. Doing a half backed nameserver will
cause operational problems. All zones are supposed to have NS and
SOA records so there is no excuse for not supporting them. As for
the other qtypes NODATA or NXDOMAIN should be returned depending
upon whether the name exists in the zone or not. Simlarly NODATA
or NXDOMAIN should be returned for NS and SOA not at the zone apex.
A nameserver doesn't have to support returning all types but it
should say that they don't exist rather than cop out with NOTIMP
or REFUSED which just cause recursive servers to move onto the next
listed server and eventually return SERVFAIL to the client.
Mark
> Anyone have any ideas?
>
> Thanks,
> Neil
>
> --
> Neil Aggarwal, (972) 834-1565
> We lend money to investors to buy or refinance single family rent houses.
> No origination fees, quick approval, no credit check.
>
>
>
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: dig ignores +notcp when doing IXFR (DiG 9.5.0-P2)
The options are processed left to right so the +notcp has to be after the ixfr=. e.g. dig ixfr= zone +notcp Note, named will for the use of TCP in its UDP response. Below is a query log of ixfr requests with and without tcp. 'T' indicates a TCP connection. 05-Dec-2013 13:11:35.681 client ::1#55802 (dv.isc.org): view external: query: dv.isc.org IN IXFR -ET (::1) 05-Dec-2013 13:11:49.664 client ::1#50513 (dv.isc.org): view external: query: dv.isc.org IN IXFR -E (::1) -- 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: dig ignores +notcp when doing IXFR (DiG 9.5.0-P2)
In message , Matthew Pounsett writes: > > On 2013-12-04, at 21:22 , Mark Andrews wrote: > > > > > The options are processed left to right so the +notcp has to be > > after the ixfr=. > > There are two reasons I don't understand why this is the case. > > 1) Since there is only one query in the command, I don't understand why > "left to right" matters. If you could do something like > dig IN IXFR= example.com +notcp IN A www.example.com +tcp > then sure.. because changing the order of options would be ambiguous, but > you can't do that. Because tcp mode isn't a tri state (unset, true, false) but a boolean and ixfr= changes it the default (false) to true. IXFR is documented as setting TCP mode. > 2) dig is generally very forgiving of argument order, so I don't see why > the location of +notcp would be any different. In these examples the arguments are independent of each other and set a single thing (even +short). The are others that set multiple things. > > dig +short @8.8.8.8 IN A cbc.ca > 159.33.3.85 > > > dig @8.8.8.8 IN A cbc.ca +short > 159.33.3.85 > > > dig IN A cbc.ca +short @8.8.8.8 > 159.33.3.85 > > > > Note, named will for the use of TCP in its UDP response. s/for/force/ > What verb is missing from this sentence? > > -- 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: dig ignores +notcp when doing IXFR (DiG 9.5.0-P2)
In message <2e1626be-94f8-44e8-a73c-6521c44ba...@conundrum.com>, Matthew Pounsett writes: > > On 2013-12-05, at 01:37 , Mark Andrews wrote: > > > > >>> Note, named will for the use of TCP in its UDP response. > > > > s/for/force/ > > Always? Regardless of response size? Interesting. What's the rationale > for doing it that way? Because TCP is always checksummed. UDP isn't. -- 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: rndc addzone, global allow-new-zones, 'file not found'
In message <2013120257.60d3bb74@loki>, Tobias Wolter writes:
>
> Hello there,
>
> I'm currently experiencing a bit of a problem with the experimental
> addzone stuff. I'm on 9.9.3-P2.
>
> I've set allow-new-zones to yes in options, and toggled
> permit-empty-zones around to no avail.
>
> My problem is that a simple addzone fails by either complaining that
> the file parameter is lacking (when not specifying one), or not being
> able to access the file (if specified):
>
> # rndc -s localhost -c ~/rndc-localhost.conf addzone metazone. '{type
> master;};'; tail /var/log/messages -n 2
> rndc: 'addzone' failed: failure
> Dec 11 10:00:31 named[21120]: received control channel command
> 'addzone metazone. {type master;};'
> Dec 11 10:00:31 named[21120]: zone 'metazone.': 'file' not
> specified
>
> # rndc -s localhost -c ~/rndc-localhost.conf addzone metazone. '{type
> master; file "master/metazone.zone";};'; tail /var/log/messages -n 4
> rndc: 'addzone' failed: file not found
> Dec 11 10:01:15 named[21120]: received control channel command
> 'addzone metazone. {type master; file "master/metazone.zone";};'
> Dec 11 10:01:15 named[21120]: zone metazone/IN: loading from
> master file master/metazone.zone failed: file not found
> Dec 11 10:01:15 named[21120]: zone metazone/IN: not loaded due
> to errors.
> Dec 11 10:01:15 named[21120]: addzone failed; reverting.
>
> From my understanding, though, the relevant configuration options should
> allow creating new zones on the fly?
>
> Any hints? (I'm a bit wary of wading through the code.)
Yes,
create the initial zone contents and put it in master/metazone.zone.
Mark
> -towo
>
--
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: rndc addzone, global allow-new-zones, 'file not found'
In message <20131211120707.11028b38@loki>, Tobias Wolter writes: > > On Wed, 11 Dec 2013 22:01:02 +1100 > Mark Andrews wrote: > > > create the initial zone contents and put it in master/metazone.zone. > > Thanks, I feared that that was a necessary step. > > No way around that requirement by built-in means, then? No. > -towo -- 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: rndc refresh fails for signed zones
In message <52a85d1b.2010...@pernau.at>, Klaus Darilion writes:
> Hi!
>
> # named -V
> BIND 9.9.3-rl.13204.02-P2
>
> I have configured slave zones with inline signing:
>
> zone "mydomain.at" {
> type slave;
> file "/etc/bind/mydomain.at";
> masters { 1.2.3.4; };
> key-directory "/etc/bind/keys";
> auto-dnssec maintain;
> inline-signing yes;
> allow-transfer { 5.6.7.8; };
> also-notify { 5.6.7.8; };
> };
>
>
> # rndc refresh mydomain.at
> rndc: 'refresh' failed: failure
> not a slave or stub zone
>
>
> For normal slave zones (unsigned) it works fine. Is this a known bug?
> Where can I open a bug report? Any workarounds?
You can report bugs to bind9-b...@isc.org. That being said this one is
trivial.
diff --git a/bin/named/server.c b/bin/named/server.c
index e7ea266..4b634f1 100644
--- a/bin/named/server.c
+++ b/bin/named/server.c
@@ -6729,7 +6729,7 @@ ns_server_notifycommand(ns_server_t *server, char *args,
isc_buffer_t *text) {
isc_result_t
ns_server_refreshcommand(ns_server_t *server, char *args, isc_buffer_t *text) {
isc_result_t result;
- dns_zone_t *zone = NULL;
+ dns_zone_t *zone = NULL, *raw = NULL;
const unsigned char msg1[] = "zone refresh queued";
const unsigned char msg2[] = "not a slave or stub zone";
dns_zonetype_t type;
@@ -6741,6 +6741,12 @@ ns_server_refreshcommand(ns_server_t *server, char
*args, isc_buffer_t *text) {
if (zone == NULL)
return (ISC_R_UNEXPECTEDEND);
+ dns_zone_getraw(zone, &raw);
+ if (raw != NULL) {
+ dns_zone_detach(&zone);
+ dns_zone_attach(raw, &zone);
+ dns_zone_detach(&raw);
+ }
type = dns_zone_gettype(zone);
if (type == dns_zone_slave || type == dns_zone_stub) {
dns_zone_refresh(zone);
>
>
> Thanks
> Klaus
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: DDNS update forwarding
In message <52a8e44a.1070...@brandeis.edu>, John Miller writes: > Hello folks, > > I'm getting ready to revamp our dynamic DNS setup here on campus, and am > curious: what is everyone doing for update forwarding? Have you seen > certain clients that will send updates based on NS records rather than > the SOA record? Which is what the update protocol specifies as the default destination to send requests to. > Perhaps a better question is: has anyone been bitten by leaving update > forwarding disabled? If you have a hidden master and clients that follow the RFC and send to the nameservers then you will need to enable update forwarding. The exact condfiguration depends on how you are authenticating updates for the zone. If it is by IP address you will need to configure the update forwarding server to use a similar acl. If you are using TSIG then you can just forward all update requests. If is off by default as it is the only safe configuration when you don't know how the master is configured not because one shouldn't forward update requests. Mark > John > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Re: missing ‘additional section’
In message <31fecd06-03b0-4efa-a6d8-91e6c2242...@ucd.ie>, "Niall O'Reilly" writ es: > > On 18 Dec 2013, at 15:19, houguanghua wrote: > > > Is there any way to enable the Additional Section? Thanks. > > The server sends data in the additional section if either > (a) these data are required, or (b) the server supports > and is configured to send data which, although not actually > required, may somehow be useful. > > The BIND named configuration option minimal-responses > controls case (b). If this is set to no, and the server > isnt sending data in the additional section, its because > it doesnt have anything useful to put there. > > As this option is part of the server configuration, there > isnt anything you can do with DiG to enable sending of > additional data. > > I hope this helps. > > Niall OReilly And as the NS records are sent that means that the zone content is incomplete. If you were not using DLZ, named would have rejected the zone as there were no address records for the nameservers. -- 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: Adding DS records
In message , David Forrest writes: > On Fri, 20 Dec 2013, Steven Carr wrote: > > > On 20 December 2013 18:10, pgndev wrote: > >> Gandi.net > >> Great support, including DNSSEC: > > > > Gandi only support DNSSEC if you host the DNS elsewhere, their DNS > > servers do not support DNSSEC. > > > > Steve > gandi.net +1 > > I transferred from NS to Gandhi in December 1998. I don't know about their > hosting of primary DNS but they do host a secondary of mine and it seems > to resolve there with an aa flag: > > ; <<>> DiG 9.10.0a1 <<>> -t rrsig @ns6.gandi.net maplepark.com +norec > ; (1 server found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64272 > ;; flags: qr aa; QUERY: 1, ANSWER: 11, AUTHORITY: 5, ADDITIONAL: 3 You don't test for dnssec support by requesting rrsigs. Nameservers can return rrsigs without supporting dnssec. You test for dnssec support by doing a request for something else with "do=1" set (+dnssec) and seeing if rrsig, nsec/nsec3/ds records are returned along with the rest of the response. -- 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: Unable to transfer IPv4 reverse zone
I think this has got to the point of running named in the foreground with debugging on the master. named -g -d 100 This will log everything to stderr. -- 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: key type change causing errors
In message <52bdee40.2070...@peak.org>, Alan Batie writes: > > I've been using bind 9.9 to do inline signing for a while > experimentally. The keys were initialized with a basic "dnssec-keygen > $zone_name". I decided to upgrade the keys from sha1 to sha256 and from > nsec to nsec3; using the instructions at > https://kb.isc.org/article/AA-00711 I moved all the old keys out and > regenerated then with "dnssec-keygen -a RSASHA256 -b 2048 -3 > $zone_name", then ran the "rndc loadkeys $zone_name" and "rndc signing > -nsec3param 1 0 10 $random_salt $zone_name" commands given, for each of > the domains. > > Several problems have now appeared after restarting named: > > 1. The log file is spewing "dns_dnssec_findzonekeys2: error reading > private key file /RSASHA1/57843: file not found" > > 2. Why is it apparently still doing sha1 when I believe I told it to > use sha256 with the keygen command. > > 3. It is still generating NSEC records, not NSEC3 records > > I've moved the old keys back and the spewing stopped, but there is one > test domain that was generating that "file not found" error even before > this attempt, even though the key is there with the rest of them > (key-directory "/var/named/keys";), so I clearly don't understand what > the error is trying to tell me... The number doesn't match so I wonder > if that's a clue? > > Dec 27 13:06:58 ns6 named[20141]: zone ghat.peak.org/IN (signed): > sending notifies (serial 2013060537) > Dec 27 13:06:58 ns6 named[20141]: dns_dnssec_findzonekeys2: error > reading private key file ghat.peak.org/RSASHA1/43536: file not found > > [475] # lf -l *ghat* > -rw-r--r-- 1 named named 435 Dec 27 13:06 Kghat.peak.org.+005+10701.key > -rw--- 1 named named 1010 Dec 27 13:06 Kghat.peak.org.+005+10701.priv= > ate > > By "number doesn't match", I mean 43536 vs 10701, which I believe is the > "key tag", but not sure where it would be getting the wrong one from? > > Thanks for any pointers... https://kb.isc.org/article/AA-00711 shows how to *start* doing DNSSEC. It does *not* describe how to do a DNSSEC key algorithm roll which is what you were attempting to do. As for "ghat.peak.org/RSASHA1/43536: file not found", 43536 is the key id of key currently in the zone. ; <<>> DiG 9.10.0a1 <<>> +multi dnskey ghat.peak.org ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31897 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;ghat.peak.org. IN DNSKEY ;; ANSWER SECTION: ghat.peak.org. 377 IN DNSKEY 256 3 5 ( AwEAAbyY10qxfkSX09VZDXaXIUYmF7qgOQQp8/oi9W4G s/71bom35cUrWia0k4K+7HKJ9H/Sgz/C8fZf90ssfJeg El37c0fnGFVkfN9aIR4za128O+bVeY8TZ1jsAWGfPhjX OumW9i8WGOtdye7BtS3Z1aAIPJrlbdmnMVmSUWR3LJaH ) ; ZSK; alg = RSASHA1; key id = 43536 ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Sat Dec 28 13:57:32 EST 2013 ;; MSG SIZE rcvd: 190 To do a DNSKEY algorithm roll you need to introduce the new keys with the new algorithm then use dnssec-settime to tell named to stop using the old keys. You also need to ensure that DS records are properly managed while this is happening and that the timing of all these events are correct. The DS records have to be removed from the parent zone and have to expired from caches before you can remove the corresponding DNSKEY records. If you don't want the zone to be treated as insecure you need to ensure that DS records for the new algorithm are published and all of the old DS RRsets have expired from cachess before you start to remove the old DS records. Before you publish the new DS records you need to ensure that all cached responses have RRSIGs for both algorithms or else validating of answers from a cache may fail. There are more timing constraints than these. If there are trust anchors for the zones in config files these also need to be accounted for. Mark -- 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: Slowing down bind answers ?
In message <52c5e922.6030...@nryc.fr>, "Nicolas C." writes:
> Hello,
>
> Is it possible to make bind answering slowly to requests ?
>
> Here is the context : we installed new DNS servers but some clients with
> static IP configuration are still using the old ones.
>
> We enabled queries logging to track the badly-configured workstations
> and warned the persons but as far as is it still working, they don't
> seem to be willing to change their static IP configuration to DHCP.
>
> Before stopping completely the old servers I'd like to slowly degrade
> the service and make the old DNS slow in order to force them to react.
>
> I'm sure it's possible to do it at a network-level (with iptables) but
> I'm curious to know if it's possible to do it directly with bind.
Newer versions of named have undocumented and subject to change
test arguments one of which is to introduce delay (-T delay=,
is in milliseconds).
If you blackhole the clients you will force the clients to switch
to another server after timing out. This is better than turning
the server off if you want to get their attention as it won't
generate ICMP unreachable.
blackhole { acl; };
After that specify a final date for them to fix their machines by
after which you will send NXDOMAIN responses. Sometimes sending a
poisoned reponse is the only way to get peoples attention.
zone "." {
type master;
file "empty";
};
empty:
@ 0 IN SOA . stop.using.this.nameserver 0 0 0 0 0
@ 0 IN NS .
@ 0 IN A 127.0.0.1
> Regards,
>
> Nicolas
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: rndc addzone gets permission denied
It is trying to create a .nzf (new zone file) file in the working directory. -- 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: dumping master file: tmp-xxx: open: permission denied
In message <8919443e-8f62-48cd-8da4-9c9632fc5...@kreme.com>, LuKreme writes: > OK, I am getting this error "dumping master file: tmp-xxx: open: > permission denied", occasionally, on both my slave DNS servers and I > can't seem to fix it. > > The dns slave files are being written into /var/named/etc/namedb/slave > which is owned by bind > > 8 drwxr-xr-x 2 bind wheel 1024 Jan 13 19:46 /var/named/etc/namedb/slave > > DNS changes are getting propagated to both servers from the master, so I > don't know where the permission denied is coming from. Where is this > tmp file being (attempted to be) written? It's trying to write the the working directory which I doubt is /var/named/etc/namedb/slave. I suspect you have a bad "file" directive. > And why are the slave servers "dumping master file" in the first place? So the slave can start up and serve the zone content when the master server is down. > -- > Carlin's Third Commandment: Thou shall keep thy religion to thyself. > > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to > unsubscribe from this list > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: specifics of downgrading from rpz2 (3rd party patch) -> rpz1 (in Bind release) ?
In message , pgndev writes: > On Mon, Jan 13, 2014 at 2:15 PM, Mark Andrews wrote: > > Why does the *need* to be info as the existing patches works other > > than for the version file which for the fix by hand is pretty > > obvious or you can just leave it as it is in 9.9.4-P2. > > The patch devs have been silent on their site, and on this list. NBD > -- their choice, of course. > > Who, other than you, has said anything about *need*? You appear to want people to supply you with a new patch because there is a minor change in the code. You were the one complaining about the lack of info. That certainly looks like you "need" info to keep using the code. "and no info on the 3rd-party rpz2 patches since the 9.9.4 release, we're downgrading to rpz1, as included in the supported Bind release (ack'd that rpz2 will be 'in' 9.10.x)." > You're of course welcome to use/apply any undocumented/unsupported > patches you choose to. Otoh, I choose to use as close to a release > product as I can functionally get away with. Me, I'm usually running unreleased code with features that havn't even make a alpha release. Yes, I eat my own dog food. > I, personally, have zero interest in playing the lab-rat to determine > what secondary/hidden effects there _might_ be by using even an > 'obvious' patch that's been, in effect, abandoned. -P's have the minimum in changes required to address the particular security problem. The existing patches work fine and unless you are paying Vernon to support you he is under no obligation to respond to you. When the previous -P came out the advice given to the list was "just apply the patch". > Tho, now that you mention it, one DOES wonder that if it's so > 'obvious', why ISC is waiting until 9.10.x to include it in the code > ... Because we broke the rule about including a chunks of new code in a non .0 release for this and additional changes are of a level where we would normally only add them at a .0 release. > In any case, my question was what the diffs are, and any hints on downgrading > . > > That's all taken care of, so - 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
Re: How to deny update of statically assgined a/ptr records?
In message , Oleg Gvozdev writes: > Hello. > > I have dynamic zone. And A record in it: > > Example(pseudo-code): > > > *zone myzone.* > * a 10.0.0.1 domain xxx* > > Then I made DHCP update for host "host.myzone." and it receives address > from dynamic range (10.0.0.10-10.0.0.100), for example: 10.0.0.10. > > > So host.myzone. has 2 A records: 10.0.0.1 and 10.0.0.10. > > How I can configure BIND to deny updating records (for example A/PTR) for > hosts, that already have static A/PTR records in DNS zone ? Normally you add prerequisites to the update request to say only add the records if there are no records of the given type. DHCPD does this by default. Mark -- 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: transfer signed zone
n+kv6mULsdH6xddCw=
> vtLmDaYokF4zsIJGdQmyXqCCg8y4A4SsivaO uM+oO1AoXLKKo3XqNEq95gg4e70yj5FNrEk9c4=
> zi0uT2TEOItBsZ9Y/T 8Gl2RDnLrjHf5YOO3py9SM/btwjZcu18TOJBWb9fbdYtKvntmG8tFlld=
> McefBwn0QJ9REmy4oXf00LKXG2xZ2E20m887j3KLzY1pYIp1GZgaRwJZ ssfreEwQpcSoz1DD4=
> MKAU0At3uCa7O8IcWx6VonhF0pZW+PzMVQGOriN 9bXLUg=3D=3Dhttp://e=
> xample.com">example.com.=
> ; 3600 IN =
> RRSIG DNSKEY 8 2 3600 20140417221308 20140116221308 15093 ref=3D"http://example.com";>example.com. KwBcvyQYmX7qDZaQfrS931Fyrf1B8z/=
> PFsXX+hYTQ1y7dIhHIEtN0WBR vyuyson0VA8PrEeUnEvWZrQL+z0Z1h9tpuFQqVWqFyBLooZAT=
> k/psPW0 7DcgXMBZ1JEq/srfJQye2MDX/iT5/+hWUJiOW+dcnIVZg2lOaehaKSQv faE=3D=
> http://ns.example.com";>ns.example.com. &nbs=
> p; 86400 IN &nbs=
> p; A 192.168.0.1http://n=
> s.example.com">ns.example.com. =
> ; 86400 IN RRSIG =
> ; A 8 3 86400 20140417221308 20140116221308 15093 http://example=
> .com">example.com. 0KgiOQwgavCWFxd5bFTtBEMXfO4yzwC8BeKYPSMqPHSdcIsLBMF7=
> wUAR YV193/OM6mTJF9vRzdlUro9kfmFBnX3xC0jVkpcpj1YVP6pTGeB8KGSk OdfC6+H658Ksc=
> B2eq/XcvFtE4VktU3QPZOW8zj4GquNpNR79fan/Idh2 OXA=3Dhttp://ns.=
> example.com">ns.example.com. &=
> nbsp; 10800 IN NSEC &n=
> bsp; http://example.com";>example.com. A RRSIG NSEC f=3D"http://ns.example.com";>ns.example.com.&nbs=
> p; 10800 IN RRS=
> IG NSEC 8 3 10800 20140417221308 20140116221308 15093 =3D"http://example.com";>example.com. Tf+bAbucKKVh7HoBaE2xZNb1yxyON/x5JC=
> PRJs9ybFi1a5eE26Thi1L0 +mrIpZVwTIwPJSfKqKO2MZePqB0fXWBq0M1HPslRbW9pjb+K+IqN=
> Si/k ybSshxj/fdkhown/a0wPZ2w0XAYY5Q8x3sc2UO2+GD8nJReAcNkO3hWe tKs=3D href=3D"http://example.com";>example.com. &=
> nbsp; 86400 IN &=
> nbsp; SOA http://ns1.example.com";>=
> ns1.example.com. http://hostmaster.example.com";>hostmaster.e=
> xample.com. 2014011701 10800 15 604800 10800http://examp=
> le.com">example.com.&nb=
> sp; 86400 IN RRSIG&nb=
> sp; SOA 8 2 86400 20140417221308 20140116221308 15093 ://example.com">example.com. alxE/TLfVRML1EAHCiVDEwmaOjaPdowXxfkompXG3M=
> wJ7tDOQcFV2O2+ 9F4TlB+l0nbfWi0mk7YWBk+w03God8RnUez9KZwhmrGAgEfWtH6kiO7A LEw=
> SPgHTS5cfQah8KGAT6o7DMWOdH0ii2EnJNzqi3gt+SR1bSPw8kTNE TOU=3D;; Query ti=
> me: 10 msec;; SERVER: 10.0.20.22#53(10.0.20.22);; WHEN: Fri Jan 17 =
> 18:44:36 EST 2014;; XFR size: 15 records (messages 7, bytes 2291)=
> Here's the=
> config:options {&nbs=
> p; directory "/opt/local"; &nb=
> sp; pid-file "server.pid"; &nb=
> sp; dnssec-enable yes; versio=
> n "SNIP";};zone "z1.example.com" IN { t=
> ype master; file "z1.example.=
> com.db";};zone "example.com" IN { type slave; r> file "secondary.example.com.db=
> "; masters {10.0.20.22; }; >};logging { =
> channel dnssec { &=
> nbsp; file "dnssec" versions 10 size 500k; >&n=
> bsp; severity debug 3; &=
> nbsp; print-category no; >&n=
> bsp; print-severity yes; =
> ; print-time yes;=
> }; =
> category dnssec {dnssec; }; &=
> nbsp; category default {default_syslog; };};<=
> br>
>
> --===6909298250656410026==
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
>
> ___
> 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
> --===6909298250656410026==--
--
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: Insecurity proof failed resolving newsletter.postbank.de - but why?
sletter.postbank.de A: in dsfetched2: ncache nxrrset > 20-Jan-2014 12:18:51.415 dnssec: debug 3: validating @0x80bb74500: > newsletter.postbank.de A: resuming proveunsecure > 20-Jan-2014 12:18:51.415 dnssec: debug 3: validating @0x80bb74500: > newsletter.postbank.de A: insecurity proof failed > > ... what? ... > > 20-Jan-2014 12:18:51.416 resolver: debug 3: fetch 0x801859ff0 (fctx > 0x80b044860(newsletter.postbank.de/DS)): destroyfetch > 20-Jan-2014 12:18:51.416 resolver: debug 3: fctx > 0x80b044860(newsletter.postbank.de/DS): shutdown > 20-Jan-2014 12:18:51.416 resolver: debug 3: fctx > 0x80b044430(newsletter.postbank.de/A): received validation completion event > 20-Jan-2014 12:18:51.416 dnssec: debug 3: validator @0x80bb74500: > dns_validator_destroy > 20-Jan-2014 12:18:51.416 resolver: debug 3: fctx > 0x80b044430(newsletter.postbank.de/A): validation failed > 20-Jan-2014 12:18:51.416 resolver: debug 3: fctx > 0x80b044430(newsletter.postbank.de/A): add_bad > 20-Jan-2014 12:18:51.416 lame-servers: info: error (insecurity proof failed) > resolving 'newsletter.postbank.de/A/IN': 195.140.184.21#53 > > Tony. > -- > f.anthony.n.finchhttp://dotat.at/ > Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. > Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, > occasionally poor at first. > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: "Recursive no;" implications?
In message <09dcbf8a-3d91-430d-beee-4e7287642...@kreme.com>, LuKreme writes: > If you set recursion no; in named.conf, you need to set the forwarders as wel > l. Is there anything else that must be done so that DNS queries still work? Forwarders will have no effect once recursion no; is set as forwarders only change the server used when named recurses. > If you have master/slave servers you should specify allow-recursion for your > subnet instead, right? I'd you do this, you don't need to set forwarders, yes? Allow-recursion has no impact on master / slave zones. > And finally, can you specify a slave DNS against a CNAME or must it have a rD > NS and an A record? No. NS records need to refer to nodes with A and/or records. Reverse DNS is irrelevent to the delegation. > For example > > NS ns1.example.com. > NS ns2.example.com. > > Ns1. A 12.34.56.789 > Ns2 CNAME name.someothername.tld > > Where the server at the CNAME doesn't have rDNS? > > > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Need help debugging my zone file
In message <52e5904e.5070...@gmail.com>, Michael Sullivan writes: > Years ago I set up a DNS server on my network. I found out last Friday > that it is no longer working. I switched to a new ISP last July and > after that, my network numbers changed from 192.168.2.? to 192.168.0.?. > I have updated my zone file, but it still doesn't work and I can't > figure out why. You made other changes than just the address changes. > Here's the output from named-checkconf: > > carter bind # named-checkconf named.conf > carter bind # > > > So named.conf is good. > > The problem I'm having is with db.espersunited.com > > Here's the output of named-checkzone: > > > > carter bind # named-checkzone espersunited.com db.espersunited.com > dns_master_load: db.espersunited.com:37: www.espersunited.com: CNAME and > other data > www.espersunited.com. IN CNAME carter.espersunited.com. > zone espersunited.com/IN: loading from master file db.espersunited.com > failed: CNAME and other data > zone espersunited.com/IN: not loaded due to errors. > carter bind # At the error message says you have a "CNAME and other data" for www.espersunited.com which you do (below). The conflicting record was detected at line 37 of file db.espersunited.com. dns_master_load: db.espersunited.com:37: www.espersunited.com: CNAME and other data www.espersunited.com. IN A 192.168.0.2 www.espersunited.com. IN CNAME carter.espersunited.com. CNAME say "the real data for the LHS is at the RHS". It is prohibited so that the resolver can know that it doesn't have to do a lookup for www.espersunited.com if it has a www.espersunited.com CNAME record cached. You need to work out which of these records you wish to keep. > carter bind # cat db.espersunited.com [snipped] > carter bind # > > I can't see anything wrong with it, but when I try to dig > carter.espersunited.com, I get > carter bind # dig carter.espersunited.com > > ; <<>> DiG 9.9.3-P2 <<>> carter.espersunited.com > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 46676 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 4096 > ;; QUESTION SECTION: > ;carter.espersunited.com. IN A > > ;; Query time: 0 msec > ;; SERVER: 127.0.0.1#53(127.0.0.1) > ;; WHEN: Sun Jan 26 16:46:11 CST 2014 > ;; MSG SIZE rcvd: 52 > > carter bind # Yep, the zone file contains a detectable error so named has refused to load it. This is required behaviour from RFC 1034/1035. Mark > SERVFAIL. What am I missing? > _______ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Variable SOAs in negative responses
In message <20140127182300.13609.qm...@joyce.lan>, "John Levine" writes: > A friend (really) asks this question: they have some DNSBLs, which get > a lot of queries. Sometimes the answer has A or TXT records, meaning > the corresponding address is listed in the DNSBL, sometimes it's > NXDOMAIN which means the address isn't. > > For addresses that aren't listed, some of the NXDOMAINs are a lot less > likely to change than others, e.g, the address of an outbound mail > server at a large mail provider is unlikely ever to be listed, but a > random host at a hosting provider in India, who knows. So he'd like > to have the TTLs on some of those NXDOMAINs be longer than others, by > putting a different TTL in the SOA in the authority section. > > The DNS server isn't BIND, coding this up is easy enough. The question > is what's likely to break at the other end. Nothing. > Question: what will BIND's cache do if there are inconsistent SOAs for > NXDOMAINS in the same zone? Nothing. Negative cache entries are independent of each other. > Bonus question: how does this answer change if we ever do DNSSEC? > (Since the server alrady generates the RRs on the fly, you can assume > it will do online signing.) Just generate the RRSIG's using the largest TTL as the original ttl. You can always send smaller TTL values as that is what you get when talking to other caches. > TIA and all that, > > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Variable SOAs in negative responses
In message <52e8258e.3060...@hireahit.com>, Dave Warren writes: > On 2014-01-28 11:28, Matus UHLAR - fantomas wrote: > > On 27.01.14 18:23, John Levine wrote: > >> A friend (really) asks this question: they have some DNSBLs, which get > >> a lot of queries. Sometimes the answer has A or TXT records, meaning > >> the corresponding address is listed in the DNSBL, sometimes it's > >> NXDOMAIN which means the address isn't. > >> > >> For addresses that aren't listed, some of the NXDOMAINs are a lot less > >> likely to change than others, e.g, the address of an outbound mail > >> server at a large mail provider is unlikely ever to be listed, but a > >> random host at a hosting provider in India, who knows. So he'd like > >> to have the TTLs on some of those NXDOMAINs be longer than others, by > >> putting a different TTL in the SOA in the authority section. > > > > If you know those IPs, why do you check them for being listed at all? > > John's question was from the point of view of the DNSBL operator. How > would a DNSBL operator stop users of that DNSBL from performing lookups > on certain IPs, and why would they bother? > > > If any IP starts spamming, why to give it longer time to appear in the > > blacklists? I don't think this makes sense at all... > > Because a lot of IPs simply are not candidates for listing at certain > types of DNSBL sites. "Too big to block" is a thing. > > A more straightforward example: If your DNSBL is designed to only list > IPs that are running vulnerable web scripts *and* are not also > legitimate mail servers, then Google's outbound MX will *never* be > candidates for listing (regardless of how much they spew) and therefore > a very large TTL'd NXDOMAIN would be appropriate. Frankly, any > legitimate mail server would be a candidate for a large-TTL'd-NXDOMAIN > for this type of list, not just big players like Google. Which if the recursive servers are following RFC 2308 will be truncated to ~3 hours. > If a DNSBL operator knows that certain IPs are not candidates for > listing (or at least not candidates for automated listing), why not let > DNS caches keep that information for as long as possible? > > -- > Dave Warren > http://www.hireahit.com/ > http://ca.linkedin.com/in/davejwarren > > Usenet is like a herd of performing elephants with diarrhea -- > massive, difficult to redirect, awe-inspiring, entertaining, and a > source of mind-boggling amounts of shit when you least expect 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 -- 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: How to query the "incoming" serial of a zone while inline signing
In message <52ea4c56.5060...@pernau.at>, Klaus Darilion writes: > Hi! > > I use Bind for inline signing between a hidden master and the public > slaves. AFAIS Bind maintains 2 serials: one for the incoming unsigned > zone (eg. used to match incoming NOTIFYs) and one for the outgoing > signed zone. > > I want to monitor if my name servers are all up2date by monitoring and > comparing the serial. This works to compare the serial of the public > slave with the outgoing serial of Bind. But if I want to know if Bind is > in sync with the hidden master, I somehow have to find out the > "incoming" serial of Bind. > > Are there any tools/ways to query Bind for the incoming serial? rndc zonestatus [class [view]] > Thanks > Klaus > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: source address problem
Given the list of source addresses is not complete Roger may want to look at: alt-transfer-source alt-transfer-source-v6 use-alt-transfer-source In message <20140204163018.ga30...@nic.fr>, Stephane Bortzmeyer writes: > On Tue, Feb 04, 2014 at 10:40:46AM +0100, > ro...@ip-plus.net wrote > a message of 19 lines which said: > > > I use the options query-source, notify-source, and transfer-source. > > Still I get outgoing queries with another source address. > > Are you sure they come from BIND and not from, say, a dig running on > the same machine. Also, these queries are sent to which server? If > it's to the local resolver, it makes sense. > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: SERVFAIL @google
Post the zone name and the actual content unaltered if you want help. Stop wasting everyones time by hiding this information. Mark In message <1900686.b2zHOhH0XN@fx>, Lucio Crusca writes: > Hello everybody, > > I have a domain which fails since a few days ago when queried @8.8.8.8, but i > f > you query it @(its nameserver) it succeeds. > > Here is my zone db > > ; > ; BIND data file for domain.org > ; > $TTL3600 > @ IN SOA domain.org. info.domain.org. ( > 2014020901 ; Serial > 1200 ; Refresh > 180 ; Retry > 3600 ; Expire > 3600); Default TTL > ; > @ IN NS ns.name. > @ IN NS ns.name. > domain.org.IN MX 10 mx.domain.org. > domain.org. IN A ip.v4.addr.ess > domain.org. IN TXT "v=spf1 a mx ?all" > domain.org.IN SPF "v=spf1 a mx ?all" > mx1 IN A ip.v4.addr.ess > mxIN A ip.v4.addr.ess > smtp IN CNAME domain.org. > pop3 IN CNAME domain.org. > pop IN CNAME domain.org. > imap IN CNAME domain.org. > www IN A ip.v4.addr.ess > www2 IN A ip.v4.addr.ess > webmail IN A ip.v4.addr.ess > mail IN A ip.v4.addr.ess > vtiger IN A ip.v4.addr.ess > shop IN A ip.v4.addr.ess > lists IN CNAME domain.org. > > > It actually works for every record, except lists.domain.org: that one works > only @nameserver, while @8.8.8.8 I get SERVFAIL. > > What am I doing wrong? > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: changing NSEC3 salt
In message <52f94ee2.7080...@ksu.edu>, "Lawrence K. Chen, P.Eng." writes: > > > On 02/06/14 15:07, Timothe Litt wrote: > > On 06-Feb-14 09:14, Klaus Darilion wrote: > >> > >> > >> On 06.02.2014 14:58, Cathy Almond wrote: > >>> On 06/02/2014 12:58, Timothe Litt wrote: > >>>> On 06-Feb-14 05:56, Cathy Almond wrote: > >>>>> On 05/02/2014 18:54, David Newman wrote: > >>>>>> The Michael W. Lucas DNSSEC book recommends changing NSEC3 salt every > >>>>>> time a zone's ZSK changes. > >>>>>> > >>>>>> Is this just a matter of a new 'rndc signing' command, or is some > >>>>>> action > >>>>>> needed to remove the old salt? > >>>>>> > >>>>>> thanks > >>>>>> > >>>>>> dn > >>>>> rndc signing -nsec3param ... > >>>>> > >>>>> I would expect the old NSEC3 chain and old NSEC3PARAM record to be > >>>>> removed, once the new chain is in place. > >>>>> > >>>>> (Similarly, the new NSEC3PARAM record will not appear in the zone > >>>>> until > >>>>> the new NSEC3 chain has been completely generated). > >>>>> > >>>>> Cathy > >>>>> > >>>> This seems silly. Why should a person have to select a salt at all? > >>>> It's just a random number, and people are really bad at picking random > >>>> numbers. Seems like a miss in 'DNSSEC for humans' :-) > >>>> > >>>> There should be a mechanism to tell named to pick a random number and > >>>> use it for the salt. (I suggest '*' - '-' already means 'none'.) > >>>> named > >>>> already has to know how to get random numbers, so this should not be > >>>> difficult. It should work for records supplied in UPDATE transactions > >>>> as well as rndc signing. > >>>> > >>>> A bit more work to have it function when loaded from a zone file, > >>>> though > >>>> that doesn't seem unreasonable. (E.g. if read from a zone file, pick a > >>>> salt, treat the record as if loaded with that value, and do all the > >>>> requisite (re-)signing.) > >>>> > >>>> I'm copying bind9-bugs so this doesn't get lost. Please don't copy > >>>> that > >>>> list if you comment on this. (Careful with that 'reply all'!) > >>>> > >>>> Timothe Litt > >>>> ACM Distinguished Engineer > >>> > >>> Sounds like a good idea - thanks. > >> > >> Indeed. It would also solve the theoretical problem of NSEC3 hash > >> collisions (see my email from 3. Feb 2014) > >> > >> regards > >> Klaus > >> > >> > > Not quite. It would enable a solution, but it doesn't solve it unless > > named also checks for a collision, picking a new salt and re-trying in > > that case. That would be a good idea (though creating a test case would > > be a good student challenge). [If it isn't tested, it doesn't work...] > > > > Note also the RFC 5155 recommendation: > >> The salt SHOULD be at least 64 bits long and unpredictable, so that > >> an attacker cannot anticipate the value of the salt and compute the > >> next set of dictionaries before the zone is published. > > In case it wasn't obvious, I should have noted that the length would be > > a config file entry. > > > > > > Timothe Litt > > ACM Distinguished Engineer > > InterestingI guess I need to keep up more on these things. > > I haven't changed my NSEC3 salt since I initially set up DNSSEC here, > and seemed to me that the document I was working off of back then said 4 > hex characters. > > Which probably made it extra hard for me to come up with a random > number. So, its totally non-random...so all I did was take the hex for > two (well-known) letters...for my salt. Since the salt is 'public', > I'll say it. my salt is "KS", or "4b53". > > So now to think of how to add NSEC3 salt changing to my current > automation scripts And for most zones it won't make a bit of difference. Most are mainly static and once you have sampled the zone enough times to hav
Re: changing NSEC3 salt
In message <52fa7d8e@networktest.com>, David Newman writes: > > It's probably worth noticing what the big operators do, e.g. > > > > $ dig +noall +answer +nottl NSEC3PARAM com. edu. net. org. > > com.IN NSEC3PARAM 1 0 0 - > > edu.IN NSEC3PARAM 1 0 0 - > > net.IN NSEC3PARAM 1 0 0 - > > org.IN NSEC3PARAM 1 0 1 D399EAAB > > > > (AFAIK the salt used for "org" has never changed - and the same value > > is used for 23 other TLDs.) A quick check revealed 216 TLDs [*] with > > NSEC3PARAM records, distributed as follows: > > > > Extra Salt length (bytes) Total > > iterations0234568 10 16 > > > > 0 7-------- 7 > > 1 --- 125--1-- 126 > > 2 ---2----1 3 > > 3 -3-1----- 4 > > 5 1--15- 151- 23 > > 8 -----2--- 2 > >10 245 25--1-- 37 > >12 ------51- 6 > >13 --1------ 1 > >15 ---1----- 1 > >17 ------1-- 1 > >25 ------2-- 2 > > 100 ------1-- 1 > > 150 ---1--1-- 2 > > > > Total 1076 15652 2721 216 > > > That's interesting. It seems to contradict Lucas' advice to "always use > '1 0 10' for these [NSEC3] flags, as fewer aren't secure enough and more > aren't any more secure." > > dn Like many things it depends apon what you are doing. Many TLD's only want NSEC3 for the OPTOUT flag. They don't care about off line enumeration. You only change the salt and use a non zero interations if you care about offline enumeration. Optout gives them 1 in x delegations with a NSEC3 record compared to every delegation with a NSEC record. They already know that most of the names in the zone are known. Somewhere around 1 in 1.x delegations is where NSEC starts taking up less space. Remember NSEC3 cannot make zone enumeration more secure than just querying the servers themselves. The idea is to make offline enumeration about as expensive as online. Mark -- 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: Trouble building bind with Openssl support
In message , "Olsen, Richard William (Rick) CTR DISA PEO-MA (US)" writes: > > We have been trying to build bind using with-openssl=PATH and not have it req > uire the full openssl install on the destination system. Why do people try to make things more complicated than they need to be. Just install openssl on the system. If you really want to go down this path then you need to copy over the shared library which is dynamically loaded into named at runtime or rebuild openssl to include the gost code in libcrypto. The windows code we ship uses the latter solution. > We had this setup an > d running when we were building on solaris 9 using bind-9.9.2 up through bind > -9.9.4-P2. Now we are building on a Solaris 10 system (remote system finally > upgraded) with bind-9.9.4-S3 and though it builds fine it errors on startup m > issing openssl libraries/files. > > Error:260B6084:engine routines:DYNAMIC_LOAD:dso not found:eng_dyn.c:449 > Error:2606A074:engine routines:ENGINE_by_id:co such engine:eng_list.c:417:id= > gost > > Bind is trying to go to the location that was referenced in the configuration > part of the build as referenced --with-openssl=. I used gcc on the solaris 9 > system but now we are going through sun studio cc for the build. > > Any help would be greatly appreciated as I expect it is something fairly simp > le I am overlooking. > > Rick. > -- 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: bind-9.9.5 regression test error
In message <52fbd79b.4070...@gmail.com>, Bruce Dubbs writes: > Christoph Moench-Tegeder wrote: > > ## Bruce Dubbs (bruce.du...@gmail.com): > > > >> I've been trying to run the regression tests for bind-9.9.5 and keep > >> getting lots of timeouts and errors in the system/inline test. > > > > I saw the same symptoms when packaging/testing bind-9.9.5. I traced > > the issue to processes blocking in read() from /dev/random - so > > adding --with-randomdev=/dev/urandom to configure's arguments made > > all tests pass. > > Thank you. Works great! Solved my problem. The inline system test uses DSA and ECDSAP256SHA256 keys both of which require random numbers to sign. If we know that there isn't a random device these algorithms are skipped. Different OS's have differing behaviours for /dev/random as well the sources of randomness differ so it is difficult to know apriori if the test will work or not. The random device can also be changed through named.conf. It is nice to see "make test" being run by someone other than us. Mark -- 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: Plugins for bind9
In message , =?ISO-8859-2?Q?Pavel_Divi=B9?= writes: > > Hello, > Is there anyone who has experience with writing plugins? In my diploma > thesis I must write plugin which must do some changes in dns request and > then forward request to processing DNS server. I can't find any > documentation or tutorials how to write plugins. Is there someone who can > help me, who has documentation (API documentation) or any experience with > writing plugins? client <-> (port 53) plugin (ephemeral port) <-> nameserver (client id space) (plugin id space) the nameserver may be running on a different port or a different address or both. the plugin uses it's own id space to talk to the nameserver. You could even use firewall rules to intercept and forward on. In this case you shouldn't need to change the query id. > Pavel -- 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: Monitoring Zonefiletransfer
In message , markus weber writes: > --===2070182502041634286== > Content-Type: multipart/alternative; boundary=001a1134888407910a04f2b6036d > > --001a1134888407910a04f2b6036d > Content-Type: text/plain; charset=UTF-8 > > Hey Guys, > > I am new to administer a Bind server and after a few problems i ran into i > need to monitor the zonefile transfers of my slave server. > I have searched on google and nagios plugin sites but could not find > anything that fits my needs entirely. > > Here is the Setup: > - MS ActiveDirectory as primary Nameservers (not under my control) > - 2 Bind server as slave for various zones (behind a loadbalancer) > > The problem i ran into, was that the zone transfer didn't work for some > reason and the zone we hold expired causing our mailgateway to stop > relaying mails :/ > > As i sayed i googled around and as i could not find anything i hacked a > nagios plugin myself ( you can find the code here > https://github.com/seppovic/Nagios-plugins/blob/master/libexec/check_dns_zone > transfer.pl). > But i am curious if i took the right "route". These are my assumptions and > a first approach: > > - read named.conf and get master servers > - query soa of slave and get serial > - query first master and get serial > - if serial match: > get zonefile modification time (not sure if this is significant) > and compare it with localtime and "soa-expiretime" > + warn or crit on threshold > (stat($zoneFile)[9] + $SOA_S->expire) - time > - if master serial > slave serial > create tempfile and check for how long it stays lower then masters > serial > + warn or crit on threshold > - else > test next master > on last master exit with error ( this should not become true ever, > right?) > > > A few problems i discovered: > - sometimes have a higher serial then all masters have, is this normal on > an AD DNS? or am I doing something wrong i thought this could not happen. Only transfer from one AD master. Microsoft AD doesn't maintain consistent serials across the servers. The serials should be monotonically increasing from a individual server. > - Some Zones nearly always reach expireation time. and i get a lot of > critical messages and a few hours/minutes before expireation it does the > update. Choose sane SOA values. refresh and retry << expire > i hope you can guide me a bit and tell me if this is what i want xD > > many thanks in advance > seppovic -- 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: cache_dump.db format and meaning
In message <20140221155053.gb76...@isc.org>, Evan Hunt writes: > On Fri, Feb 21, 2014 at 03:47:25PM +0700, Mr.Jittinan Suwanrueangsri wrote: > > I have dumped cached records from BIND > > 9.8.2rc1-RedHat-9.8.2-0.17.rc1.el6_4.6 by using "rndc dumpdb -cache". > > I don't understand the meaning of "; pending-answer" and "; > > pending-additional" in cache_dump.db.What do these mean? > > It means "pending validation". These records have not been subjected to > DNSSEC validation and are therefore considered less trustworthy than if > they had been. If a validated version of the same information comes along > in the future, then this existing cache data will be discarded in favor of > it. pending-* is there for lazy validation. These records are learnt as a side effect of some other query. Rather than validating them immediately they are validated when requested using the data in the cache. The differences indicate the trust level the answers get if they then validate as insecure. If the cache does not contain all the information required to validate we currently recurse and validate that response. A future change would be to just fetch the missing data rather than a full recursion. If the validation fails we just recurse. > -- > Evan Hunt -- e...@isc.org > Internet Systems Consortium, Inc. > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: dig +sigchase looping
gt; > > > lack; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM:= > 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid;= > BORDER-RIGHT: medium none; PADDING-TOP: 3pt"> > From: Ray Walker < lto:ray.wal...@nau.edu">ray.wal...@nau.edu> > Date: Friday, February 21, 2014 at = > 4:28 PM > To: "mailto:bind-us= > e...@lists.isc.org">bind-users@lists.isc.org" < :bind-users@lists.isc.org">bind-users@lists.isc.org> > Subject: dig +sigchase looping<= > br> > > > > > -break: after-white-space;"> > ize: 14px;"> > I=92m experiencing an interesting issue where sometimes when performing a s= > igchase on a valid signed zone the command loops indefinitely when an expir= > ed RRSIG exists: > ize: 14px;"> > > > ize: 14px;"> > Live example: > dig +sigchase +trusted-key= > =3D./trusted.keys aa.nau.edu A > ize: 14px;"> > > > ize: 14px;"> > Notes: > ize: 14px;"> > There is currently a valid RRSIG for this zone. > ize: 14px;"> > dig compiled with -DDIG_SIGCHASE=3D1 > ize: 14px;"> > BIND 9.9.4 > ize: 14px;"> > > > ize: 14px;"> > Roughly %50 of the time it returns as expected, while other times looping i= > n such a fashion: > ize: 14px;"> > > > > ;; OK a DS valids a DNSKEY in the RR= > set > ;; Now verify that this DNSKEY valid= > ates the DNSKEY RRset > ;; VERIFYING DNSKEY RRset for aa.nau= > .edu. with DNSKEY:25159: RRSIG has expired > ;; OK a DS valids a DNSKEY in the RR= > set > ;; Now verify that this DNSKEY valid= > ates the DNSKEY RRset > ;; VERIFYING DNSKEY RRset for aa.nau= > .edu. with DNSKEY:25159: RRSIG has expired > ;; OK a DS valids a DNSKEY in the RR= > set > ;; Now verify that this DNSKEY valid= > ates the DNSKEY RRset > ;; VERIFYING DNSKEY RRset for aa.nau= > .edu. with DNSKEY:25159: RRSIG has expired > ;; OK a DS valids a DNSKEY in the RR= > set > ;; Now verify that this DNSKEY valid= > ates the DNSKEY RRset > ;; VERIFYING DNSKEY RRset for aa.nau= > .edu. with DNSKEY:25159: RRSIG has expired > ;; OK a DS valids a DNSKEY in the RR= > set > ;; Now verify that this DNSKEY valid= > ates the DNSKEY RRset > ;; VERIFYING DNSKEY RRset for aa.nau= > .edu. with DNSKEY:25159: RRSIG has expired > ;; OK a DS valids a DNSKEY in the RR= > set > ;; Now verify that this DNSKEY valid= > ates the DNSKEY RRset > ;; VERIFYING DNSKEY RRset for aa.nau= > .edu. with DNSKEY:25159: RRSIG has expired > > ize: 14px;"> > > > ize: 14px;"> > Any particular reason this should be expected or is it bug worthy (or fixed= > in 9.9.5, as I didn=92t see anything in the change log referring to it)? div> > ize: 14px;"> > =97 > Raymond Walker > > Software Systems Engineer StSp. > ITS - Northern Arizona University > > > > > > > > > --_000_CF30C95B14D22raywalkernauedu_-- > > --===5278526947618159597== > Content-Type: text/plain; charset="us-ascii" > MIME-Version: 1.0 > Content-Transfer-Encoding: 7bit > Content-Disposition: inline > > ___ > 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 > --===5278526947618159597==-- -- 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: Configure error - openSSL. Mac OS X
Go back to the orginal configure args and post the errors from config.log. -- 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: Configure error - openSSL. Mac OS X
The first thing is that configure has decided that we are cross
compiling which is because the simple executable did not run.
configure:3472: checking whether we are cross compiling
configure:3510: result: yes
I haven't upgraded my machine to Mavericks yet so I can't test this.
The version of clang you are using works with 10.8.5 so the first
thing I would do is make sure you are completely up to date at the
OS level.
The program that configure is trying to compile and run is:
#include
int
main ()
{
FILE *f = fopen ("conftest.out", "w");
return ferror (f) || fclose (f) != 0;
;
return 0;
}
So I would do that by hand.
gcc -o conftestconftest.c
./conftest
If that fails open a bug report with Apple.
Mark
--
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: Configure error - openSSL. Mac OS X
In message , James Brown wri
tes:
>
> On 11 Mar 2014, at 2:15 pm, Mark Andrews wrote:
>
> >
> > The first thing is that configure has decided that we are cross
> > compiling which is because the simple executable did not run.
> >
> > configure:3472: checking whether we are cross compiling
> > configure:3510: result: yes
> >
> > I haven't upgraded my machine to Mavericks yet so I can't test this.
> > The version of clang you are using works with 10.8.5 so the first
> > thing I would do is make sure you are completely up to date at the
> > OS level.
> >
> > The program that configure is trying to compile and run is:
> >
> > #include
> > int
> > main ()
> > {
> > FILE *f = fopen ("conftest.out", "w");
> > return ferror (f) || fclose (f) != 0;
> >
> > ;
> > return 0;
> > }
> >
> > So I would do that by hand.
> >
> > gcc -o conftestconftest.c
> > ./conftest
>
> gcc can't find contest.c, and neither can I!
>
> BordoDNS:bind-9.9.5 me$ gcc -o conftestconftest.c
> clang: error: no such file or directory: 'conftest.c'
> clang: error: no input files
I didn't think I would need to say "save the contents of the program to
conftest.c".
cat > conftest.c << 'EOF'
#include
int
main ()
{
FILE *f = fopen ("conftest.out", "w");
return ferror (f) || fclose (f) != 0;
;
return 0;
}
EOF
gcc -o conftestconftest.c
./conftest
> James.
> --
> 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: Configure error - openSSL. Mac OS X
Mark Andrews writes:
>
> In message , James Brown w
> ri
> tes:
> >
> > On 11 Mar 2014, at 2:15 pm, Mark Andrews wrote:
> >
> > >
> > > The first thing is that configure has decided that we are cross
> > > compiling which is because the simple executable did not run.
> > >
> > > configure:3472: checking whether we are cross compiling
> > > configure:3510: result: yes
> > >
> > > I haven't upgraded my machine to Mavericks yet so I can't test this.
> > > The version of clang you are using works with 10.8.5 so the first
> > > thing I would do is make sure you are completely up to date at the
> > > OS level.
> > >
> > > The program that configure is trying to compile and run is:
> > >
> > > #include
> > > int
> > > main ()
> > > {
> > > FILE *f = fopen ("conftest.out", "w");
> > > return ferror (f) || fclose (f) != 0;
> > >
> > > ;
> > > return 0;
> > > }
> > >
> > > So I would do that by hand.
> > >
> > > gcc -o conftestconftest.c
> > > ./conftest
> >
> > gcc can't find contest.c, and neither can I!
> >
> > BordoDNS:bind-9.9.5 me$ gcc -o conftestconftest.c
> > clang: error: no such file or directory: 'conftest.c'
> > clang: error: no input files
>
> I didn't think I would need to say "save the contents of the program to
> conftest.c".
>
> cat > conftest.c << 'EOF'
> #include
> int
> main ()
> {
> FILE *f = fopen ("conftest.out", "w");
> return ferror (f) || fclose (f) != 0;
>
> ;
> return 0;
> }
> EOF
> gcc -o conftestconftest.c
> ./conftest
and add "echo $?" at the end to report the exit status.
> > James.
> > --
> > Mark Andrews, ISC
> > 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Configure error - openSSL. Mac OS X
In message <54602b24-14d9-42b4-ad2e-55adf4805...@bordo.com.au>, James Brown wri
tes:
>
> On 11 Mar 2014, at 4:09 pm, Mark Andrews wrote:
>
> >
> > I didn't think I would need to say "save the contents of the program to
> > conftest.c".
> >
> > cat > conftest.c << 'EOF'
> > #include
> > int
> > main ()
> > {
> > FILE *f = fopen ("conftest.out", "w");
> > return ferror (f) || fclose (f) != 0;
> >
> > ;
> > return 0;
> > }
> > EOF
> > gcc -o conftestconftest.c
> > ./conftest
>
> Getting further now!
>
> $ cat > conftest.c << 'EOF'
> > #include
> > int
> > main ()
> > {
> > FILE *f = fopen ("conftest.out", "w");
> > return ferror (f) || fclose (f) != 0;
> >
> > ;
> > return 0;
> > }
> > EOF
> BordoDNS:bind-9.9.5 jlbrown$ gcc -o conftestconftest.c
> BordoDNS:bind-9.9.5 jlbrown$ ./conftest
> BordoDNS:bind-9.9.5 jlbrown$
>
> James.
Also which version of OpenSSL did you compile?
Mark
--
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: Internal clients' queries for "myhostname." get sent to forwarders. Why?
The search algorithms in libresolve/libbind are a compromise. If I had my way, back when libresolv was updated for RFC 1535, support for partially qualified domain names would have died. ndots was the compromise. Searches would have only continued on NXDOMAIN and unqualified names would not have been tried against the root. There were obvious security and information leakage issues with partially qualified names. So to with continuing searches on NODATA and SERVFAIL. I have been setting hostname to the fully qualified value for the last 20 years or so. The worked on almost all platforms but some needed tweaking to remove assumptions that a hostname was a single label. Also whenever a hostname is added to a configuration file / script the fully qualified version is used. I killed searching in the local sendmail configurations and forced everyone to use fully qualified names in mail. This reduced problems once people got used to it. Mark -- 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: How to create a fake root server?
In message <53216b43.8040...@gmail.com>, Peter writes: > Hi Kevin, > > Thanks for your reply. It's just for a closed internal network with no > access to the rest of the internet. Making labs such as testing ISP > functions and services, mail servers etc. Everything is running inside > an VMware host with an internal closed network. > > I have created a closed "Internet" on 172.16.x.x where I would like to > put up a root server for .loc, where several other ISP-DNS servers, with > domains, are referred to. I've managed to create those "ISP-DNS" servers > which works fine. But I'm having trouble to create the root DNS server > with Bind. I haven't found any useful examples at the web yet. Perhaps because a root zone is like any other zone. It has a SOA record and NS records at the apex and other records. . 3600 SOA server.example.net. hostmaster.example.net. 1 3600 1200 2419200 3600 . 3600 NS server.example.net. . 3600 NS another.example.net. server.example.net. 3600 A 1.2.3.4 another.example.net. 3600 A 1.2.3.5 > It's for a school project. > > Regards, Peter > > > On 12/03/14 19:56, Kevin Darcy wrote: > > First of all, don't use .loc as an internal TLD. There are *many* > > proposals in process with ICANN for establishing new TLDs, and for all > > you know, .loc might be one of them. If .loc gets established on the > > Internet, and you're using it internally, that presents abundant > > opportunities for confusion and failure. > > > > Use a publically-registered domain, a descendant of a > > publically-registered domain, or potentially, one of the reserved TLDs > > in RFC 6761. > > > > I'm not sure what your question is, exactly. Set up the root zone, > > slave it, publish 2 or more of the master/slaves in the NS records, > > delegate whatever TLD you're going to use, set up *that* zone, lather, > > rinse, repeat, for the entire hierarchy. Anyone who reads > > _DNS_and_BIND_ should be able to set up an internal-root > > infrastructure, IMO (although, sadly, the later editions don't seem as > > aligned to internal-root as they used to be). > > > > - Kevin > > > > > > On 3/12/2014 11:07 AM, Peter wrote: > >> Hi guys, > >> > >> I'm doing a virtual internet (internal net) for several VPS's. My > >> goal is to simulate the Internet root servers and the ISP:s domain > >> servers, which are hosting the actual domains. I want to the create > >> several DNS nameservers that will contain the specific domain under > >> the "xxx.loc, yyy.loc, zzz.loc". > >> > >> 1 server for the .loc root > >> 3 servers for xxx.loc (server1), yyy.loc (server2), zzz.loc (server3) > >> > >> Running BIND 9 at every server. > >> > >> Any suggestions or good links are highly appreciated. > >> > >> Best regards, > >> Peter > >> ___ > >> 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 -- 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: Update Security
If you are going to forward updates use TSIG or SIG(0) to sign the
update and stop worrying about addresses. TSIG and SIG(0) are
billions and billions of times stronger authenticators than a IP
address.
"allow-update-forwarding { any; };" says forward all updates
regardless of the address they were sent from.
As for you question. Addresses are not preserved so A doesn't know
it came from E unless the messages are signed.
Mark
In message
, Bob McDonald writes:
>
> I want to confirm my understanding of security of DDNS updates.
>
> I have a stealth master "A" feeding slave "B" and "C".
>
> I have allow-update-forwarding { any; } specified on "B" and "C".
>
> If a client "D" presents an update to "B" or "C" it will automatically be
> forwarded to "A".
>
> If "B" or "C" are in the allow-updates ACL on "A" all updates will be
> applied.
>
> If "D" is in the allow-udates ACL on "A" (and not "B" or "C") the updates
> from "D" will be applied. However an update from "E" presented to "B" or
> "C" will be forwarded but not processed.
>
> Is this correct?
No.
> Bob
>
> --001a11337302fad9ea04f49380b0
> Content-Type: text/html; charset=ISO-8859-1
> Content-Transfer-Encoding: quoted-printable
>
> I want to confirm my un=
> derstanding of security of DDNS updates.I have a stealth mast=
> er "A" feeding slave "B" and "C". v>
> I have allow-update-forwarding { any; } specified on "B" and &quo=
> t;C".If a client "D" presents an update to &qu=
> ot;B" or "C" it will automatically be forwarded to "A&q=
> uot;.
> If "B" or "C" are in the allow-updates ACL on=
> "A" all updates will be applied.If "D" i=
> s in the allow-udates ACL on "A" (and not "B" or "=
> C") the updates from "D" will be applied.=A0 However an upda=
> te from "E" presented to "B" or "C" will be f=
> orwarded but not processed.
> Is this correct?Bob
>
> --001a11337302fad9ea04f49380b0--
>
> --===4542560060445475228==
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
>
> ___
> 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
> --===4542560060445475228==--
--
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: bind tools on windows wait forever
Use BIND 9.9.5-W1. Mark In message <9jawi1csarsretigbud1n5h0.1395229889...@email.android.com>, Gaurav K ansal writes: > Hi Matus, > > I also notice the same thing. > This may be an issue or any other feature in bind tool which is producing thi > s result. > I did it on windows 8, so I think that may be 8 and bind 9.9.5 is producing t > his and I didn't do much troubleshooting on this. > > Sent frm Kansal's Mobile > Sry for typo error :) > > Matus UHLAR - fantomas wrote: > > >Hello, > > > >I have installed bind 9.9.5 on windows (tools only) and when I execute dig, > >host or even nslookup, they return output but don't exit so I must break > >(Ctrl-C) them. > > > >Did anyone notice such behaviour? > > > >-- > >Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ > >Warning: I wish NOT to receive e-mail advertising to this address. > >Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. > >Windows 2000: 640 MB ought to be enough for anybody > >___ > >Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscrib > e 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 -- 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: bind tools on windows wait forever
I would so that you only have a single version on the system. That said only dig, host and nslookup tickle this bug so you could get away with not upgrading. Mark -- 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: Bind 9.9.1 forward zone "local"
".local" is reserved for mDNS. I would say stop trying to use ".local" in the DNS. Mark -- 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: Bind 9.9.1 forward zone "local"
In message <53324030.1080...@hireahit.com>, Dave Warren writes: > On 2014-03-25 16:16, Mark Andrews wrote: > > ".local" is reserved for mDNS. I would say stop trying to use ".local" in > > the DNS. > > While true, I don't think it will help this particular issue. As I > understand it, BIND knows, by knowledge of being a root server, that > local. can't possibly exist, and so that knowledge overrides the > configuration of the forwarder. Correct. > I ran into similar setting up a fake/virtual TLD for wrbldnsd, which I > was able to resolve by moving it downstream to dnsbl.hireahit.net. > instead of just dnsbl. Nearly. Until I hit one broken application that > wouldn't work with this configuration. > > Switching BIND to use hints instead of acting as a root seems to work > around this (broken) local configuration. Truly one shouldn't be defining one's own tlds. There lies dragons. One should use space delegated to you. If you don't have space delegated to you explictly, one can use 10.in-addr.arpa. It may not be pretty but it is a hostname suffix and it is delegated for anyone to use. > -- > Dave Warren > http://www.hireahit.com/ > http://ca.linkedin.com/in/davejwarren > > > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: High recursive client counts
In message , Scott Bertilson writes: > > This got me to take a look at "rndc recursing" on one of our servers. > > It is disappointing that queries for the same FQDN/type/class from the same > client (different source port and query ID though) are handled individually > rather than being merged somehow. Is this because of the ID or the source > port, both, or something else? What makes you think they are not merged? Named detects duplicates. It has self tuning limits on the number of simultaneous clients for the FQDN/type/class tuple dropping clients if there are too many. It also drops duplicates where the source port and address are duplicated. Named still has to reply to all the clients which is why they are on the recursing list. Mark -- 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: DNS64 and DNSSEC - AD bit not set (RFC 6147)
In message , Tom Lanyon wri tes: > Hi list, > > Just wanted to check my understanding of BIND9's implementation of DNS64 agai > nst RFC 6147. > > Currently BIND9's "break-dnssec" defaults to "no" - in this configuration, a > security-aware & validating recursive resolver with will never synthesise a A > AAA record via DNS64 when queried with DO=1 irregardless of the CD bit. No. If the answer is secure and DO=1 then it won't synthesis. RFC 6147 just gets DO and CD semantics completely wrong. The WG wanted there to be signaling that the client was going to validate and DNSSEC does not have such signaling. The best DNSSEC can do is DO=1 indicates that the client might validate. This is independent of CD. A validating stub resolver should send it queries with CD=0 so that the recursive server can filter out bad responses from upstream. Only if it gets SERVFAIL should it attempt the query with CD=1 in case the resolver has bad time or bad trust anchors. Named doesn't lie when DO=1 *and* it is possible to detect the lie. "break-dnssec yes;" tells named to lie even when it is possible to detect the lie. Stub resolvers don't currently set DO=1 so DNS64 synthesis happens for them. > When changing "break-dnssec" to "yes", querying with DO=1 will always trigger > synthesis of a DNS64 record, irregardless of the CD bit. > > Both of these configurations seem to conflict with the DNS64 RFC 6147, which > specifies that (so long as the upstream negative and positive A response > s validate) the recursive resolver can still synthesise the DNS64 when q > ueried with DO=1 and CD=0 but must return the answer with the AD bit set. On > ly when queried with both DO=1 and CD=1 must it not synthesise the DNS64 > . > > Is there any way to configure BIND9 to comply with this RFC 6147 behaviour? > We're on 9.8.2, but I couldn't find anything related in the CHANGES for eithe > r 9.8 or 9.9. > > Thanks, > Tom > > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNS64 and DNSSEC - AD bit not set (RFC 6147)
In message , Tom Lanyon wri tes: > On 27 Mar 2014, at 14:48, Mark Andrews wrote: > > No. If the answer is secure and DO=1 then it won't synthesis. > > > > RFC 6147 just gets DO and CD semantics completely wrong. The WG > > wanted there to be signaling that the client was going to validate > > and DNSSEC does not have such signaling. The best DNSSEC can do > > is DO=1 indicates that the client might validate. This is independent > > of CD. > > Isn't this signalling defined as the purpose of the CD bit in RFC 4035? > > My naive understanding is something like: > > DS=1 CD=0 "I am not going to validate this, I want you to check it" > DS=1 CD=1 "I am going to validate this, so I don't care if you check it" Which is incorrect. I presume you mean DO not DS. DO=1 says "I understand DNSSEC records, send them to me if you have them" it also says "set AD as appropriate" (AD=1 can also be used to request setting AD as appropriate in the response). CD=1 says "Do not validate records from upstream if you have to make upstream queries, pass them through to me without checking" it also stop validation checks being made on other lookups needed to complete the lookup being made. Think of CD=1 as "Give me the answer even if the lookup would normally fail due to DNSSEC validation failures". There is no "I will be validating responses" on either of these. DNSSEC does not have a way to signal "I will be validating responses". The authors of RFC 6147 really wanted there to be such a signal and tried to twist the DNSSEC signaling bits into signaling this. This is like defining pi to be 3. It does not work. > > A validating stub resolver should send it queries with CD=0 so that > > the recursive server can filter out bad responses from upstream. > > Only if it gets SERVFAIL should it attempt the query with CD=1 in > > case the resolver has bad time or bad trust anchors. > > Right, this is what our current stub resolvers are doing (well, I'm not > sure about the retry with CD=1 on SERVFAIL, but they're sending DS=1 CD=0 > queries to our recursive resolvers). > > > > Named doesn't lie when DO=1 *and* it is possible to detect the lie. > > "break-dnssec yes;" tells named to lie even when it is possible to > > detect the lie. > > So, what is a "lie" here? Assuming that the response received upstream > (i.e. a negative and positive A response) has been validated, is > inserting a synthesised for DNS64 "lying"? Yes, it is lying. It's deliberate lying but it is lying. The same policy applies to othe places where named can be configured to lie. > > Stub resolvers don't currently set DO=1 so DNS64 synthesis happens > > for them. > > Our real-world case, and why I'm looking into this, is that our BIND > 9.8.2 validating recursive resolvers are *not* returning synthesised > DNS64 responses for DNSSEC signed zones because the downstream stub > resolvers query with DS=1 and CD=0. This breaks connectivity from our > IPv6-only clients for DNSSEC signed zones. > > As far as I can see, my two options are to enable break-dnssec in BIND, > or disable DNSSEC validation in the stub resolvers. Are there any other > options, and if not, are either of these two more preferred than the > other? Or teach the stub resolvers how to discover the DNS64 parameters. The sane way to do that would have been a EDNS option but the working group decided heuristics are good enough. > Tom > -- 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: Problems with auto-dnssec maintain on BIND 9.9.5 (latest patch, FreeBSD)
In message <5333fe7a.8030...@dialtelecom.cz>, Daniel Ryslink writes:
> Hello,
>
> I have the following zone definition included into named.conf:
>
> zone "example.com" in {
> type master;
> file "master/example.com";
> update-policy local;
> auto-dnssec maintain;
> key-directory "/etc/namedb/keys/";
> masterfile-format text;
> inline-signing yes;
> };
>
> Keys are ready in /etc/namedb/keys/, readable for the named process.
>
> At first, when the zone was not signed at all, all that sufficed was to
> do "rndc loadkeys example.com", and when I later used "rndc signing
> -list example.com", the keys set via
> dnssec-settime as active in the keys directory were displayed.
>
> Now, the system reverted into a state where rndc signing -list
> example.com states that no signing records were found.
Which is normal. The signing records record which DNSKEYs are
in the process of signing the entire zone for the first time.
They are not needed after this completes which is why there is
rndc signing --clear.
> rndc loadkeys
> says nothing, but the return code is 0 (success?). However, when I
> export the new zone file into master/example.com, it is no longer signed
> automatically as before.
You are using "inline-signing yes;" the signed version of the zone is
in master/example.com.signed.
> Manual "rndc sign" still work without problems,
> and results in a zone correctly signed with the active keys. It's only
> the auto mode that was broken.
>
> Also. named.log for bind displays curiously frequent key events:
>
> 27-Mar-2014 08:36:01.899 general: info: zone example.com/IN (signed):
> next key event: 27-Mar-2014 09:36:01.895
> 27-Mar-2014 08:39:01.633 general: info: zone example.com/IN (signed):
> reconfiguring zone keys
> 27-Mar-2014 08:39:01.637 general: info: zone example.com/IN (signed):
> next key event: 27-Mar-2014 09:39:01.633
> 27-Mar-2014 08:41:01.825 general: info: zone example.com/IN (signed):
> reconfiguring zone keys
> 27-Mar-2014 08:41:01.829 general: info: zone example.com/IN (signed):
> next key event: 27-Mar-2014 09:41:01.825
> 27-Mar-2014 08:48:01.447 general: info: zone example.com/IN (signed):
> reconfiguring zone keys
> 27-Mar-2014 08:48:01.450 general: info: zone example.com/IN (signed):
> next key event: 27-Mar-2014 09:48:01.447
> 27-Mar-2014 08:52:02.094 general: info: zone example.com/IN (signed):
> reconfiguring zone keys
> 27-Mar-2014 08:52:02.097 general: info: zone example.com/IN (signed):
> next key event: 27-Mar-2014 09:52:02.094
> 27-Mar-2014 09:52:02.100 general: info: zone example.com/IN (signed):
> reconfiguring zone keys
>
> Why a key event every five minutes, when TTL of the records is 6 hours?
Presumably because dnssec-loadkeys-interval is set to 5 minutes.
TTL is how long keys are cached. It has nothing to do with how often
named looks for new keys (dnssec-loadkeys-interval) or when a key is
scheduled to be added/removed/actived/inactivated which are key events.
> Many thanks in advance to anyone who could possibly bring some insight
> into the problem.
>
> PS.: The name of the actual domain was obviously changed to protect our
> customers.
Which of course prevents anyone doing any sanity checking / investigation
on what you are reporting.
> --
> Best regards,
> Daniel Rylink
> System Administrator
>
> Dial Telecom a. s.
> Kikova 36a/237
> 186 00 Praha 3, esk Republika
> Tel.:+420.226204627
> daniel.rysl...@dialtelecom.cz
> ---
> www.dialtelecom.cz
> Dial Telecom, a.s.
> Jednodue se pipojte
> -------
>
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: High recursive client counts
In message <53349e66.8050...@ksu.edu>, "Lawrence K. Chen, P.Eng." writes: > > > On 03/26/14 04:02, Sam Wilson wrote: > > In article , > > Jason Brandt wrote: > > > >> For now, I've disabled DNS inspection on our firewall, as it is an ancient > >> Cisco firewall services module, and that seems to have stabilized things, > >> but it's only been 30 minutes or so. Until I get a few days in, I'll keep > >> researching. > > > > We used to run DNS inspection on our FWSMs. We didn't notice any issues > > with DNS resolution per se, but we did find that turning it off dropped > > the FWSM CPU from ~70% to less than 30%. We're not aware of any issues > > that using DNS inspection might have caused. > > > > Sam > > > > I had to get our DNS servers exempted from our Procera, as it was interfering > DNSSEC. The security analyst said it considered some of the large encrypted > UDPs as P2P. > > So, every few days (less during busy times), a recursive caching query server > would stop answeringwhere restarting it would make it work again. It was > to the point where I had our monitoring system restart bind as needed. > > Eventually, my manager asked about all strange notifications. Where he then > pushed it up to the CISO to get the analyst to make the change to stop > interfering with DNS. > > They had done a test a few months earlier, and said we didn't complain then. > I went back through the logs, and found that it had been interfering > then...but the weekend test wasn't enough to cause any servers to stop > responding. > > I didn't think to see what the client counts were. Though another time when > the Procera had stopped passing any traffic, the counts did get really high > before they stopped working. > > Need to work on figuring out how to have it resolve local domains when > Internet connection is down. Slave the local zones is the simplest solution. > -- > Who: Lawrence K. Chen, P.Eng. - W0LKC - Sr. Unix Systems Administrator > For: Enterprise Server Technologies (EST) -- & SafeZone Ally > _______ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: socket error on ipv6 link local
Just mark fe80::/10 as bogus. records do not have
enough information in them to disambiguate link-local
addresses and map them to per machine scope id's.
server fe80::/10 { bogus yes; };
Mark
In message <009501cf4dec$1b097920$511c6b60$@meganet.net>, "Paul A" writes:
> Im going to change bind to just listen on specified ipv6 addresses to see
> what happens.
>
>
>
> -Original Message-
> From: bind-users-bounces+razor=meganet@lists.isc.org
> [mailto:bind-users-bounces+razor=meganet@lists.isc.org] On Behalf Of
> ca35763+b...@realsimplemail.com
> Sent: Tuesday, April 01, 2014 4:35 PM
> To: bind-users@lists.isc.org
> Subject: RE: socket error on ipv6 link local
>
> I'm getting the same errors with bind-9.10.0b2.
>
> Just a guess but I think it's related to using a HE IPv6 Tunnel and the
> updated root servers.
>
> On Tue, 1 Apr 2014, Paul A wrote:
>
> > Date: Tue, 1 Apr 2014 16:25:43 -0400
> > From: Paul A
> > To: 'Kevin Darcy' , bind-users@lists.isc.org
> > Subject: RE: socket error on ipv6 link local
> >
> > So Kevin what your saying is someone using my dns created a record
> > with fe80::? I was under the impression that bind what trying to
> > listen on that subnet.
> >
> >
> >
> > Thanks Paul
> >
> >
> >
> > From: bind-users-bounces+razor=meganet@lists.isc.org
> > [mailto:bind-users-bounces+razor=meganet@lists.isc.org] On Behalf
> > Of Kevin Darcy
> > Sent: Tuesday, April 01, 2014 4:02 PM
> > To: bind-users@lists.isc.org
> > Subject: Re: socket error on ipv6 link local
> >
> >
> >
> > My guess would be that some miscreant out there created a glue
> > record with an RDATA of "fe80::" and your network stack balks at
> > connecting to such an abomination.
> >
> >
> > - Kevin
> >
> > On 4/1/2014 2:31 PM, Paul A wrote:
> >
> > Hi, I have been using bind 9.9.4 for awhile suddenly looking at the
> > looks I see lots of socket.c errors. Looking at this it seems that
> > bind is complaining about the link local ipv6 address , I enabled ipv6
> > awhile back and I just noticed this.
> >
> >
> >
> > Apr 1 13:05:32 ns1 named[18769]: connect(fe80::#53) 22/Invalid
> > argument
> >
> > Apr 1 13:05:32 ns1 named[18769]: socket.c:5351: unexpected error:
> >
> > Apr 1 13:05:32 ns1 named[18769]: connect(fe80::#53) 22/Invalid
> > argument
> >
> > Apr 1 13:05:32 ns1 named[18769]: socket.c:5351: unexpected error:
> >
> > Apr 1 13:05:32 ns1 named[18769]: connect(fe80::#53) 22/Invalid
> > argument
> >
> > Apr 1 13:05:32 ns1 named[18769]: socket.c:5351: unexpected error:
> >
> > Apr 1 13:05:32 ns1 named[18769]: connect(fe80::#53) 22/Invalid
> > argument
> >
> >
> >
> >
> >
> >
> >
> > Aside from having my global ipv6 addresses here is the link local on
> > that box.
> >
> >
> >
> > inet6 addr: fe80::206:5bff:fe8e:/64 Scope:Link
> >
> >
> >
> >
> >
> > Has anyone ran into this issue, I do have listen-on-v6 { any; }; and
> > im assuming if I was to just add the global ipv6 ips this would go
> > away but I guess im wondering does bind not listen bind itself to link
> > local ip as well ? what is the recommended way to go about fixing this.
> >
> >
> >
> >
> >
> > BIND 9.9.4 (Extended Support Version) built with
> > '--enable-rrl'
> >
> >
> >
> >
> >
> > Thanks, Paul
> >
> >
> >
> >
> >
> >
> > ___
> > Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> > unsubscribe from this list
> >
> > bind-users mailing list
> > bind-users@lists.isc.org <mailto: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
--
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: Example of classless reverse-lookup zone
You should read all the error messages. dns_rdata_fromtext: junk:3: near 'i...@example.com': bad name (check-names) i...@example.com should be "it.example.com." The first label is everything to the left of the @ in the email address. If it has periods in it they need to be escaped. Also how do you expect anyone to solve the rest of your problems when you don't give a example and you don't give the real names involved. We are not mind readers. Mark -- 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: Example of classless reverse-lookup zone
In message , Dimitar Georgievski writes: > > Thanks Mark. Although this wasn't my first priority I corrected the issue > with the label is well. > > I thought I provided an example of my problem, no? > > Dimitar You stated "I tried adding check-names ignore; to the zone definition in named.conf, which removed the bad-name errors but it didn't resolve the reverse lookup problem for this subnet." and that was it. It's a bit hard to help after that. B.T.W. named doesn't care about the owner names of PTR records. It does care about the rdata content if the owner name ends in "in-addr.arpa" or "ip6.arpa". Mark > On Mon, Apr 7, 2014 at 7:08 PM, Mark Andrews wrote: > > > > > You should read all the error messages. > > > > dns_rdata_fromtext: junk:3: near 'i...@example.com': bad name (check-names) > > > > i...@example.com should be "it.example.com." The first label is > > everything to the left of the @ in the email address. If it has > > periods in it they need to be escaped. > > > > Also how do you expect anyone to solve the rest of your problems > > when you don't give a example and you don't give the real names > > involved. We are not mind readers. > > > > Mark > > -- > > Mark Andrews, ISC > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org > > > > --089e011764e98af1d704f67f6c7e > Content-Type: text/html; charset=ISO-8859-1 > Content-Transfer-Encoding: quoted-printable > > Thanks Mark. Although this wasn't my first priority I = > corrected the issue with the label is well.=A0I thought= > I provided an example of my problem, no?Dimitar<= > /div> > On Mon,= > Apr 7, 2014 at 7:08 PM, Mark Andrews < to:ma...@isc.org" target=3D"_blank">ma...@isc.org> wrote:= > x #ccc solid;padding-left:1ex"> > > You should read all the error messages. > > dns_rdata_fromtext: junk:3: near 'mailto:i...@example.com";>it@= > example.com': bad name (check-names) > > mailto:i...@example.com";>i...@example.com should be " hre= > f=3D"http://it.example.com"; target=3D"_blank">it.example.com." =A0= > The first label is > everything to the left of the @ in the email address. =A0If it has > periods in it they need to be escaped. > > Also how do you expect anyone to solve the rest of your problems > when you don't give a example and you don't give the real names > involved. =A0We are not mind readers. > > Mark > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2= > 9871 4742 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 INTERNET: ma...@isc.org">ma...@isc.org > > > --089e011764e98af1d704f67f6c7e-- -- 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: All, do bind9.9.5 support edns0-client-subnet?
In message , "=?ISO-8859-1?B?bGlu?=" writes: > All,In bind 9.9.5 release notes, I found these messages. > > Check that EDNS subnet client options are well formed. RT #34718 > > is it means the bind 9.9.5 support edns0-client-subnet? both used as > authoritative server and recursive server. No. edns0-client-subnet will require a significant re-write of the resolver and cache to support. This is currently unfunded work. > thanks. -- 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: Cross compile bind failing, vis3 ???
You are cross compiling. You need to set BUILD_* so that the host tools are properly built. % grep BUILD README BUILD_CC BUILD_CFLAGS (optional) BUILD_CPPFLAGS (optional) BUILD_LDFLAGS (optional) BUILD_LIBS (optional) % Mark In message , "Olsen, Richard William (Rick) CTR DISA PEO-MA (US)" writes: > > We have a remote site that we are providing a bind package for. They want a ta > rgeted build and sent us the compile options as > > -xtarget=T3 -xarch=sparcvis3 -xchip=ultraT3 -xcache=8/16/4:6144/64/24 > > The build system is using Sun Studio 12.3 cc on T5140 (UtltraSPARC-T2+ hardwa > re running Solaris 10 05/08.) > > isainfo -x >sparcv9: asi_blk_init vis2 vis popc >sparc: asi_blk_init vis2 vis poppc v8plus div32 mul32 > > Now the problem. I can compile the openssl using his requested parameters but > the bind fails. > > "./gen -s . -c > include/dns/enumclass.h > Ld.so.1: gen: fatal: hardware capability (CA_SUNW_HW_1) unsupported: 0x500 [ V > IS3 FMAF ] > Bash: line 1 killed ./gen -s . -c > include/dns/enumclass.h > *** Error code 1 > The following command caused the error: > For I in isc isccc dns isccfg bind9 lwres tests nulldir; do \ > if [ "$i" != "nulldir" -a -d $i ]; then \ > echo "making all in `pwd'/$i"; \ > (cd $i; make DESTDIR="/blah/blah/bind-9.9.5-S1/lib" all ) || exi > t 1; \ > fi; \ > done > make: Fatal error: Command failed for target 'subdirs' > " > > Does bind not support Vis 3 architecture? > -- 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: Promoting a slave to master gives syntax error
Set the masterfile-format. Slaves default to raw,
masters default to text.
masterfile-format ( text | raw );
Mark
In message <535f4bb2.6000...@theo-andreou.org>, Theodotos Andreou writes:
> Hello to all,
>
> I have a task to clone a black box IPAM to a bind DNS server. Actually
> the black box is using bind in the backend but the manufacturer does not
> provide any shell access. Only a crappy GUI. So I do not have access to
> the text zone files. Just the GUI.
>
> In order to clone all the zones from the original DNS to the clone, I
> setup a bind in slave config and allowed zone transfers for it. This is
> a sample config:
>
> /etc/bind/named.conf.local:
>
> ... Output omitted ...
>
> zone "16.2.10.in-addr.arpa" {
> type slave;
> file "db.16.2.10.in-addr.arpa";
> masters { 10.1.12.61; };
> };
>
> zone "24.3.10.in-addr.arpa" {
> type slave;
> file "db.24.3.10.in-addr.arpa";
> masters { 10.1.12.61; };
> };
>
> ... Output omitted ...
>
> After bind restart, the zone transfers an all zones are completed
> successfully. The resultant files are some sort of binary:
>
> # file /var/cache/bind/db.24.3.10.in-addr.arpa
> /var/cache/bind/db.24.3.10.in-addr.arpa: data
>
> Now to promote the server to master I changed the configuration to:
>
> /etc/bind/named.conf.local:
>
> ... Output omitted ...
>
> zone "16.2.10.in-addr.arpa" {
> type master;
> file "db.16.2.10.in-addr.arpa";
> };
>
> zone "24.3.10.in-addr.arpa" {
> type master;
> file "db.24.3.10.in-addr.arpa";
> };
>
> ... Output omitted ...
>
> But when I restart bind I get a lot of errors like this:
>
> named[19773]: dns_master_load: db.24.3.10.in-addr.arpa:1: syntax error
> named[19773]: zone 24.3.10.in-addr.arpa/IN: loading from master file db.24.3
> .10.in-addr.arpa failed: syntax error
> named[19773]: zone 24.3.10.in-addr.arpa/IN: not loaded due to errors.
>
> Apparently the systems expects to see a zone file in text format but
> because it's in binary it fails. I also tested it with:
>
> # named-checkzone 24.3.10.in-addr.arpa /var/cache/bind/db.24.3.10.in-addr.arp
> ... Output omitted ...
> dns_master_load: /var/cache/bind/db.24.3.10.in-addr.arpa:16: syntax error
> dns_master_load: /var/cache/bind/db.24.3.10.in-addr.arpa:16: syntax error
> dns_master_load: /var/cache/bind/db.24.3.10.in-addr.arpa:16: syntax error
> dns_master_load: /var/cache/bind/db.24.3.10.in-addr.arpa:16: syntax error
> dns_master_load: /var/cache/bind/db.24.3.10.in-addr.arpa:16: syntax error
> dns_master_load: /var/cache/bind/db.24.3.10.in-addr.arpa:16: syntax error
> dns_master_load: /var/cache/bind/db.24.3.10.in-addr.arpa:17: syntax error
> /var/cache/bind/db.24.3.10.in-addr.arpa: file does not end with newline
> zone 24.3.10.in-addr.arpa/IN: loading from master file /var/cache/bind/db.24.3
> .10.in-addr.arpa failed: syntax error
> zone 24.3.10.in-addr.arpa/IN: not loaded due to errors.
>
> I know I must be doing something fundamentally wrong here but I couldn't
> find a guide how to do this properly. Any ideas?
>
> I am using bind version 9.9.5-3-Ubuntu ( the stock binary that comes
> with Ubuntu 14.04 64 bit) and the compiled parameters are:
> named[7817]: built with '--prefix=/usr' '--mandir=/usr/share/man'
> '--infodir=/usr/share/info' '--sysconfdir=/etc/bind'
> '--localstatedir=/var' '--enable-threads' '--enable-largefile'
> '--with-libtool' '--enable-shared' '--enable-static'
> '--with-openssl=/usr' '--with-gssapi=/usr' '--with-gnu-ld'
> '--with-geoip=/usr' '--with-atf=no' '--enable-ipv6' '--enable-rrl'
> '--enable-filter-' 'CFLAGS=-fno-strict-aliasing -DDIG_SIGCHASE -O2'
>
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Cross compile bind failing, vis3 ???
You do it something like this. Note the argument to --host MUST NOT match what sh config.guess returns. ./configure CC=cc CFLAGS="-Xa -fast -xstrconst -xchip=ultraT3 -xarch=sparcvis3 -mt -m64" --host=sparcvis3-sun-solaris2.10 --with-randomdev=/dev/random --with-ecdsa=no --with-gost=no BUILD_CC=cc BUILD_CFLAGS= Note there is a call to ../../tools/gengrandom that fails at the moment when cross compiling so run "make -k" or run 'make' until it fails on genrandom, cd to bin/tools and run 'rm genrandom genrandom.o' then 'make gengrandom CC=cc CFLAGS=""' then restart the original make. This should result in a generic sparc build of gengrandom which should run all on sparc processors. Mark In message , "Olsen, Richard William (Rick) CTR DISA PEO-MA (US)" wri tes: > --=_NextPart_000_004E_01CF6388.DB10FF20 > Content-Type: text/plain; > charset="us-ascii" > Content-Transfer-Encoding: 7bit > > Well, I tried with the BUILD_CC and BUILD_CFLAGS set. I hadn't noticed the > cross compile test during configuration before since it has be > en working for the T1000 and T5140 builds. Now though it has "no" for the > cross compile test. > > Here is my configure command: (this is in a script that sets path to the > solaris studio bin) > > BUILD_CC=cc BUILD_CFLAGS="-Xa -fast -xstrconst -xchip=ultraT3 > -xarch=sparcvis3 -mt -m64" ./configure --with-openssl=/usr/local/ssl --enab > le-full-report --without-gost --exec-prefix=/usr > --libexecdir=/usr/lib/libexec --includedir=/usr/include > > Even after I edit the configure script to have cross_compile=yes, it still > responds with no during the configuration. > > -Original Message- > From: Mark Andrews [mailto:ma...@isc.org] > Sent: Monday, April 28, 2014 12:05 PM > To: Olsen, Richard William (Rick) CTR DISA PEO-MA (US) > Cc: bind-users@lists.isc.org > Subject: Re: Cross compile bind failing, vis3 ??? > > > You are cross compiling. You need to set BUILD_* so that the host tools > are properly built. > > % grep BUILD README > BUILD_CC > BUILD_CFLAGS (optional) > BUILD_CPPFLAGS (optional) > BUILD_LDFLAGS (optional) > BUILD_LIBS (optional) > % > > Mark > > In message > >, "Olsen, Richard William (Rick) CTR DISA PEO-MA (US)" writes: > > > > We have a remote site that we are providing a bind package for. They want a > > ta > > rgeted build and sent us the compile options as > > > > -xtarget=T3 -xarch=sparcvis3 -xchip=ultraT3 -xcache=8/16/4:6144/64/24 > > > > The build system is using Sun Studio 12.3 cc on T5140 (UtltraSPARC-T2+ > > hardwa > > re running Solaris 10 05/08.) > > > > isainfo -x > >sparcv9: asi_blk_init vis2 vis popc > >sparc: asi_blk_init vis2 vis poppc v8plus div32 mul32 > > > > Now the problem. I can compile the openssl using his requested parameters > > but > > the bind fails. > > > > "./gen -s . -c > include/dns/enumclass.h > > Ld.so.1: gen: fatal: hardware capability (CA_SUNW_HW_1) unsupported: 0x500 > > [ V > > IS3 FMAF ] > > Bash: line 1 killed ./gen -s . -c > include/dns/enumclass.h > > *** Error code 1 > > The following command caused the error: > > For I in isc isccc dns isccfg bind9 lwres tests nulldir; do \ > > if [ "$i" != "nulldir" -a -d $i ]; then \ > > echo "making all in `pwd'/$i"; \ > > (cd $i; make DESTDIR="/blah/blah/bind-9.9.5-S1/lib" all ) || exi > > t 1; \ > > fi; \ > > done > > make: Fatal error: Command failed for target 'subdirs' > > " > > > > Does bind not support Vis 3 architecture? > > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org > > --=_NextPart_000_004E_01CF6388.DB10FF20 > Content-Type: application/x-pkcs7-signature; name="smime.p7s" > Content-Transfer-Encoding: base64 > Content-Disposition: attachment; filename="smime.p7s" > > MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISpzCCA3Aw > ggJYoAMCAQICAQUwDQYJKoZIhvcNAQEFBQAwWzELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4g > R292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxFjAUBgNVBAMTDURvRCBSb290 > IENBIDIwHhcNMDQxMjEzMTUwMDEwWhcNMjkxMjA1MTUwMDEwWjBbMQswCQYDVQQGEwJVUzEYMBYG > A1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEWMBQGA1UE > AxMNRG9EIFJvb3Qg
Re: How to disable DNSSEC/EDNS for lwresd
In message <483759859.6291670.1398781076480.javamail.zim...@redhat.com>, Tomas H
ozza writes:
> Hi.
>
> I'm trying to disable DNSSEC/EDNS for the lwresd using the
> following lwresd.conf:
>
> options {
> directory "/var/named/";
>
> dnssec-enable no;
> dnssec-validation no;
>
> pid-file "/run/named/lwresd.pid";
> session-keyfile "/run/named/session.key";
> };
>
> lwres {
> search {example1.;};
> ndots 1;
> };
>
> But it seems that the 'dnssec-enable no;' statement has no
> influence on the EDNS usage in queries sent by lwresd.
"dnssec-enable no;" controls how named responds to DO=1 queries.
It is a no-op to lwresd as it is not processing DNS requests.
> I was able to disable EDNS when lwres is run as named
> using:
>
> server 0.0.0.0/0 {
> edns no;
> };
>
> server ::/0 {
> edns no;
> };
Just add the server clauses to lwresd.conf.
"lwresd -c lwresd.conf" is running as lwresd
"lwresd -C resolv.conf" is running as lwresd
"lwresd" is the same as "lwresd -C /etc/resolv.conf"
"named -c named.conf" (with a lwres clause) is running as both named and lwresd
"named -c named.conf" (without a lwres clause) is running as just named
> in the configuration. However I was not able to disable EDNS
> when running lwresd.
>
> We have a user that would like to disable EDNS to reduce the
> overhead it adds and improve the performance. The DNSSEC is
> not a priority for them.
>
> Is there way to disable DNSSEC/EDNS for lwresd?
>
> Thank you in advance.
>
>
> Regards,
> --
> Tomas Hozza
> Software Engineer - EMEA ENG Developer Experience
>
> PGP: 1D9F3C2D
> Red Hat Inc. http://cz.redhat.com
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: GSS-TSIG updates from Windows clients
See tkey-gssapi-credential ; tkey-gssapi-keytab ; grant ms-subdomain ; -- 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: BIND 9.10 compilation problem for FreeBSD 6.x/7.x
In message , Tony Fi nch writes: > Shawn Zhou wrote: > > > Any problem has problem building BIND 9.10 for FreeBSD? We are using the > > same process that worked for building 9.9.4 to build 9.10 on FreeBSD > > 6.x/7.x but we are getting "ld: invalid BFD target" error. > > Yes. BIND's linking stage changed between 9.9 and 9.10 so instead of > invoking cc to link, its build scripts now invoke ld directly. If you used > to use -Wl to escape linker flags you must now pass them unescaped. > > My build used to have > export LDFLAGS="-Wl,-R/opt/OpenSSL/lib" > but now has > export LDFLAGS="-R/opt/OpenSSL/lib" It's more that there is a loadable object being built to test loading of dynamicably loadable drivers. Most of the linking is still done through $CC. Also one shouldn't need to add LDFLAGS="-R/opt/OpenSSL/lib". configure adds it itself if the platform needs it. --with-openssl=/opt/OpenSSL should be enough. > Tony. > -- > f.anthony.n.finchhttp://dotat.at/ > Southwest Forties, Cromarty, Forth, Tyne, Northwest Dogger: Southerly or > southwesterly 4 or 5. Slight or moderate. Showers. Good, occasionally > moderate. > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: bind 9.10.0 xfer test failing
In message <2ddim91ft8u2u4uelvoqeajer8idpj6...@4ax.com>, "J. Thomsen" writes: > I am wondering why a particular test of 9.10.0 is failing and how it can be= > fixed. > It happens repeatedly with linux on two different hardware platforms. > > I:System test result summary: > I: 1 FAIL > I: 63 PASS > I: 4 SKIPPED > > T:xfer:1:A > A:System test xfer > I:testing basic zone transfer functionality > I:testing TSIG signed zone transfers > I:reload servers for in preparation for ixfr-from-differences tests > I:ns1 server reload successful > I:ns2 server reload successful > I:ns3 server reload successful > I:ns6 server reload successful > I:ns7 server reload successful > I:updating master zones for ixfr-from-differences tests > I:ns1 server reload successful > I:ns2 server reload successful > I:ns6 server reload successful > I:ns7 server reload successful > I:testing zone is dumped after successful transfer > I:testing ixfr-from-differences yes; > I:testing ixfr-from-differences master; (master zone) > I:testing ixfr-from-differences master; (slave zone) > I:testing ixfr-from-differences slave; (master zone) > I:testing ixfr-from-differences slave; (slave zone) > I:check that a multi-message uncompressable zone transfers > I:testing that incorrectly signed transfers will fail... > I:initial correctly-signed transfer should succeed > --10.53.0.5:5301 at ../send.pl line 33. > I:ns4 server reload successful > I:failed > I:unsigned transfer > --10.53.0.5:5301 at ../send.pl line 33. (trace inserted by me) > Connection refused at ../send.pl line 34. > I:bad keydata > --10.53.0.5:5301 at ../send.pl line 33. > Connection refused at ../send.pl line 34. > I:partially-signed transfer > --10.53.0.5:5301 at ../send.pl line 33. > Connection refused at ../send.pl line 34. > I:unknown key > --10.53.0.5:5301 at ../send.pl line 33. > Connection refused at ../send.pl line 34. > I:incorrect key > --10.53.0.5:5301 at ../send.pl line 33. > Connection refused at ../send.pl line 34. > I:exit status: 1 > I:ans5 died before a SIGTERM was sent > R:FAIL ans5 is a perl based nameserver. Net::DNS, which it uses, has been changing recently. If you roll back Net::DNS to version 0.72 the test should succeed. "ans" needs to be rewritten in parts to work with the with the new Net::DNS. > - J=F8rgen Thomsen > > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscri= > be from this list > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.10.0 is now available
In message <9cd0cbfd-743d-455a-9000-6ceb8d926...@bordo.com.au>, James Brown wri tes: > I can't download the source for 9.10.0. > > www.isc.org/downloads/# > > Click on Download for 9.10.0. Modal-1 appears. > > Click on BIND 9.10.0 - tar.gz. > > It tries to download: > > http://www.isc.org/downloads/file/bind-9-10-0b1-2/?version=tar.gz > > and fails. Looks like that link is wrong. > > Anyone else having problems? > > Thanks, > > James. It downloads fine for me. You can also use the following links. http://ftp.isc.org/isc/bind9/9.10.0 ftp://ftp.isc.org/isc/bind9/9.10.0 Mark -- 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: RPZ and www.rackspace.com
rif"> > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: > 30337 > > ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: > 0 > > > ;; QUESTION SECTION: face="sans-serif"> > ; face="sans-serif">www.rackspace.com ize=2 face="sans-serif">. > IN > A > > > ;; ANSWER SECTION: > face="sans-serif">www.rackspace.com t size=2 face="sans-serif">. > 300 IN CNAME > face="sans-serif">www.wip.rackspace.com > . > > face="sans-serif">www.wip.rackspace.com > . > 30 IN A > 173.203.44.116 > > ;; Query time: 193 msec face="sans-serif"> > ;; SERVER: redacted face="sans-serif"> > ;; WHEN: Wed May 7 08:53:08 2014 size=2 face="sans-serif"> > ;; MSG SIZE rcvd: 73 > > > > dig @redacted.cat.com color=blue face="sans-serif">www.rackspace.com< > /u> > > > ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.17.rc1.el6_4.6 <<>> > @redacted.cat.com face="sans-serif">www.rackspace.com< > /font> > > ; (1 server found) face="sans-serif"> > ;; global options: +cmd face="sans-serif"> > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: > 25905 > > ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: > 0 > > > ;; QUESTION SECTION: face="sans-serif"> > ; face="sans-serif">www.rackspace.com ize=2 face="sans-serif">. > IN > A > > > ;; ANSWER SECTION: > face="sans-serif">www.rackspace.com t size=2 face="sans-serif">. > 298 IN CNAME > face="sans-serif">www.wip.rackspace.com > . > > > ;; AUTHORITY SECTION: face="sans-serif"> > wip.rackspace.com. 58 IN > SOA www-gtm-ord1.rackspace.com. > hostmaster.305181-GTM1.rackspace.com. > 86 10800 3600 604800 60 > > ;; Query time: 2 msec face="sans-serif"> > ;; SERVER: redacted face="sans-serif"> > ;; WHEN: Wed May 7 08:53:10 2014 size=2 face="sans-serif"> > ;; MSG SIZE rcvd: 129 > > > David A. Evans > Enterprise IP/DNS Management > Network Infrastructure Tools and Services color=blue> > mailto:evans_davi...@cat.com> color=blue>evans_davi...@cat.com > > ___ > Please visit href="https://lists.isc.org/mailman/listinfo/bind-users";> size=2>https://lists.is > c.org/mailman/listinfo/bind-users > to unsubscribe from this list > > bind-users mailing list > bind-users@lists.isc.org > href="https://lists.isc.org/mailman/listinfo/bind-users";> size=2>https://lists.isc.org/mailman > /listinfo/bind-users > > --=_alternative 0054318186257CD1_=-- > > --===1900647751663457684== > Content-Type: text/plain; charset="us-ascii" > MIME-Version: 1.0 > Content-Transfer-Encoding: 7bit > Content-Disposition: inline > > ___ > 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 > --===1900647751663457684==-- -- 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: Point domain name of my zone to name in somebody else's zone?
In message <536aaf39.6000...@ksu.edu>, "Lawrence K. Chen, P.Eng." writes: > DNAME ? No. DNAME redirects the names under it. It does not redirect the owner name. > On 05/06/14 11:44, Rom, Gloria wrote: > > Yup, that=92s what I was asking. Thanks. > > = > > > = > > > = > > > Gloria Rom > > = > > > UCLA Library Digital Initiatives and Information Technology > > = > > > glor...@library.ucla.edu <mailto:glor...@library.ucla.edu> > > = > > > 310-206-9784 > > = > > > = > > > = > > > *From:*bind-users-boun...@lists.isc.org > > [mailto:bind-users-boun...@lists.isc.org] *On Behalf Of *Kevin Darcy > > *Sent:* Tuesday, May 06, 2014 9:39 AM > > *To:* bind-users@lists.isc.org > > *Subject:* Re: Point domain name of my zone to name in somebody else's zo= > ne? > > = > > > = > > > = > > > The apex name of a zone can't own a CNAME, if that's what you're asking. = > E.g. > > the name "example.com" can't be a CNAME pointing at "otherexample.com". > > = > > > But, of course, you can certainly put A and/or records at the apex, = > that > > resolve to one or more addresses in one or more ranges you don't own/cont= > rol. > > = > > > = > = > > > - Kevin > > = > > > On 5/6/2014 12:31 PM, Rom, Gloria wrote: > > = > > > Hello All, > > = > > > = > > > = > > > Here=92s an easy one. > > = > > > = > > > = > > > I administer a zone that consists of a few names, each of which point= > s to > > a name in a zone that I do not administer. > > = > > > = > > > = > > > Now my project manager wants to resolve the domain name of my zone to > > another name in that foreign zone. > > = > > > = > > > = > > > Can I tell him that it can=92t be done, or have I overlooked a clever > > workaround? I=92m running an oldish version of BIND 9. > > = > > > = > > > = > > > Thanks, > > = > > > = > > > = > > > Glo > > = > > > = > > > = > > > Gloria Rom > > = > > > UCLA Library Digital Initiatives and Information Technology > > = > > > glor...@library.ucla.edu <mailto:glor...@library.ucla.edu> > > = > > > 310-206-9784 > > = > > > = > > > = > > > = > > > = > > > = > > > ___ > > = > > > Please visit https://lists.isc.org/mailman/listinfo/bind-users to uns= > ubscribe from this list > > = > > > = > > > = > > > bind-users mailing list > > = > > > bind-users@lists.isc.org <mailto:bind-users@lists.isc.org> > > = > > > https://lists.isc.org/mailman/listinfo/bind-users > > = > > > = > > > = > > > = > > > = > > > ___ > > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubsc= > ribe from this list > > = > > > bind-users mailing list > > bind-users@lists.isc.org > > https://lists.isc.org/mailman/listinfo/bind-users > > = > > > -- = > > Who: Lawrence K. Chen, P.Eng. - W0LKC - Sr. Unix Systems Administrator > For: Enterprise Server Technologies (EST) -- & SafeZone Ally > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscri= > be from this list > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: No-Sync-at-Slave
In message <003c01cf6a8d$3a0a72d0$ae1f5870$@cyberia.net.sa>, "Mohammed Ejaz" wr ites: > > > I have a primary and secondary name server which host a number of domains. > Recently, the secondary has started failing to sync one of the domains, and > comes up with the following Assuming the IP addresses is correct something is filtering the TCP connections. DNS uses *both* TCP and UDP. It is a myth that TCP is only used for zone transfers. Properly configured nameservers answer on both TCP and UDP. 212.93.192.4 only answers on UDP. > May 7 22:51:12 ns2 named[1381]: [ID 873579 daemon.error] transfer of > 'domain.com/IN' from 212.93.192.4#53: failed to connect: timed out > > May 7 21:35:06 ns2 named[1381]: [ID 873579 daemon.error] transfer of > 'domain.com/IN' from 212.93.192.4#53: failed to connect: timed out > > May 7 21:43:31 ns2 named[1381]: [ID 873579 daemon.error] transfer of > 'domain.com/IN' from 212.93.192.4#53: failed to connect: timed out > > > > > > Any one's help would be highly appreciated thanks in advance. > > > > Regards > > Ejaz > -- 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: Point domain name of my zone to name in somebody else's zone?
In message <536bcced.8060...@hireahit.com>, Dave Warren writes: > On 2014-05-08 07:45, Barry Margolin wrote: > > In article , > > Tony Finch wrote: > > > >> Dave Warren wrote: > >>> DNSMadeEasy calls this an "ANAME" record, internally they just lookup the > >>> destination's IP and cache it, updating it as needed. > >>> > >>> It works, but it would be nice if this could be done in DNS. Sadly, it > >>> can't, > >>> and probably won't in our lifetimes. > >> Never say never :-) > >> > >> You can implement something ANAME-alike with a script that polls the > >> A and records at the target name and does a DNS UPDATE on the owner > >> as necessary, but that might not scale too well. > >> > >> There are a couple of difficulties with implementing ANAME inside the > >> server. > >> > >> Firstly it implies a weird authoritative/recursive hybrid. A bit ugly but > >> not unreasonable. > >> > >> Secondly, and more importantly, is the question of how this works with > >> zone transfers and secondaries. How do you ensure they support ANAME > >> records? Do you include a backwards compatibility hack by adding the A and > >> records to the zone? > > It also has adverse implications for DNS-based CDN routing, e.g. Akamai. > > Everyone will be routed to the servers close to the auth servers of the > > domain containing the ANAME, instead of routing each end user to their > > closest servers. > > Indeed. Were such a thing implemented, I'd think it would be smart to > have the authoritative server return both the ANAME and A records, > allowing a compliant resolver to do it's own A record lookup to find an > appropriate CDN endpoint, while older resolvers with no concept of ANAME > would simply ignore it and use the (possibly-less-than-optimal) A record. > > Arguably adjusting CNAME to allow it to coexist with other record types > might be a better long-term solution, perhaps allowing CNAME to coexist > with SOA, NS and DNAME records? But that does not help when you want a MX record at the apex or some other record at the apex. CNAME is not and never has been the correct solution for this. The problem is that CNAME "works" for www.example.net because only address records are put at www.example.net. This covered 99.9% of use initially. SRV or a HTTP specific record like MX is the correct solution. However it requires browser vendors to be on board change the initial lookup and then fallback to A/ if the record does not exist. > Although allowing a CNAME to coexist > with NS could have some interesting side effects. There might be > backward compatibility issues that make this impossible, but I would > hazard a guess that since DNAMEs already return a matching CNAME and > nothing explodes, the problems would be minor and limited in scope. > > -- > Dave Warren > http://www.hireahit.com/ > http://ca.linkedin.com/in/davejwarren > > > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Point domain name of my zone to name in somebody else's zone?
In message <536c0392.3020...@hireahit.com>, Dave Warren writes: > On 2014-05-08 15:09, Mark Andrews wrote: > > In message <536bcced.8060...@hireahit.com>, Dave Warren writes: > >> On 2014-05-08 07:45, Barry Margolin wrote: > >>> In article , > >>>Tony Finch wrote: > >>> > >>>> Dave Warren wrote: > >>>>> DNSMadeEasy calls this an "ANAME" record, internally they just lookup > >>>>> the > >>>>> destination's IP and cache it, updating it as needed. > >>>>> > >>>>> It works, but it would be nice if this could be done in DNS. Sadly, it > >>>>> can't, > >>>>> and probably won't in our lifetimes. > >>>> Never say never :-) > >>>> > >>>> You can implement something ANAME-alike with a script that polls the > >>>> A and records at the target name and does a DNS UPDATE on the owner > >>>> as necessary, but that might not scale too well. > >>>> > >>>> There are a couple of difficulties with implementing ANAME inside the > >>>> server. > >>>> > >>>> Firstly it implies a weird authoritative/recursive hybrid. A bit ugly but > >>>> not unreasonable. > >>>> > >>>> Secondly, and more importantly, is the question of how this works with > >>>> zone transfers and secondaries. How do you ensure they support ANAME > >>>> records? Do you include a backwards compatibility hack by adding the A > >>>> and > >>>> records to the zone? > >>> It also has adverse implications for DNS-based CDN routing, e.g. Akamai. > >>> Everyone will be routed to the servers close to the auth servers of the > >>> domain containing the ANAME, instead of routing each end user to their > >>> closest servers. > >> Indeed. Were such a thing implemented, I'd think it would be smart to > >> have the authoritative server return both the ANAME and A records, > >> allowing a compliant resolver to do it's own A record lookup to find an > >> appropriate CDN endpoint, while older resolvers with no concept of ANAME > >> would simply ignore it and use the (possibly-less-than-optimal) A record. > >> > >> Arguably adjusting CNAME to allow it to coexist with other record types > >> might be a better long-term solution, perhaps allowing CNAME to coexist > >> with SOA, NS and DNAME records? > > But that does not help when you want a MX record at the apex or > > some other record at the apex. > > I'd argue that it does -- Since the record is now CNAME'd, the MX record > is now under the control of the destination of the CNAME record and MX > records can still be set. This is no different than if I CNAME'd > dog.example.com to cat.example.com, email to @dog.example.com will flow > to the MX records of cat.example.com. > > Not ideal? Well no, it's not. Don't use a CNAME if you don't want to > delegate everything, instead use a HTTP/HTTPS level redirect to www. > which is properly distributed. > > ANAME records might be more flexible, but since they require > authoritative servers to gain resolver-like capabilities to provide > backward compatible A-records, I believe that the concept will be a > non-starter outside of proprietary solutions that just update A records > dynamically. ANAME is service agnostic. If it exists it should be implemented in the applications not the nameserver. A and should be additional data. > > SRV or a HTTP specific record like MX is the correct solution. > > However it requires browser vendors to be on board change the initial > > lookup and then fallback to A/ if the record does not exist. > > Agreed, and I touched upon this in one of my earlier replies. I wish you > the best of luck pushing the world toward using SRV records; it would > solve a lot of problems, but they seem to scare too many people. > > I actually think that MX records were a boneheaded thing to do, had > email started using SRV records in the first place we might be in a > position now where using SRV records is the defacto standard if not the > actual standard for all services. (No offense to the folks that made MX > records happen, I realize that in historical context it was the correct > decision and it solved the very immediate problem -- I'm just saying > that in an ideal world, SRV records instead of MX records would solved > the same problem in a more generic fashion, and would have pushed us to > a better place for other protocols) MX works for wildcards. SRV doesn't work for wildcards. "* CNAME " is often used which is why SRV is not such a good fit. > -- > Dave Warren > http://www.hireahit.com/ > http://ca.linkedin.com/in/davejwarren > > -- 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: Bind 9.10 64 bit
In message , Giovanni Paterno' writes: > O.S. Windows 2008 R2 64 bit. Up to now I have used Bind 32 bit, now I see t= > hat a 64 bit version is available. > Should I move to 64 bit version ? If yes is there any how to doc ? > > Giovanni Paterno Uninstall the 32 bit version preserving data. Install the 64 bit version. 9.10.0 changes the default install location so you may want to move your data across. x86: CSIDL_PROGRAM_FILESX86 x64: CSIDL_PROGRAM_FILES -- 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: bin 9.10 verbose logging
In message <1399664632.4864.59.ca...@ns.five-ten-sg.com>, Carl Byington writes:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Sat, 2014-05-03 at 14:28 -0500, Jeremy C. Reed wrote:
> > "We didn't get a OPT record in response to a EDNS query." and also
> > says "We need to drop/remove the logging here when we have more
> > experience."
>
> Is there a sample dig query that can reproduce this? I see such a
> message in my log files regarding domain of interest to me.
>
> For the OP's question, presumably something like
>
> dig dns2.osogrande.com @207.66.8.132 +?
Modern versions of DiG turn on EDNS by default.
+[no]edns[=version]
+[no]dnssec (implies +edns)
If there is a OPT record in the response you will see something
like this:
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
or
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; NSID: 72 6f 63 6b 2e 64 76 2e 69 73 63 2e 6f 72 67 ("rock.dv.isc.org")
; SIT: 8cd65ccfb9f282d53599db62536d5c39ec27d9c7420ccbbe (good)
; EXPIRE: 2389987 (3 weeks 6 days 15 hours 53 minutes 7 seconds)
If you turn on some of the EDNS options (+sit +nsid +expire) in the
request.
+sit(source identity token) provides 64 additional bits of randomness
to make of path spoofing virtually impossible to achieve. It
also provides a method for servers to know they are talking to
a client that have talked to before so they don't need to
rate limit responses (uses a experimental code point).
+nsid (name server identifier)
+expire how long to go before the zone expires (code point 9 has been
assigned for this, 9.10.0 uses a experimental code point and
will be changed in 9.10.1 to the assigned code point).
Mark
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2.0.14 (GNU/Linux)
>
> iEYEARECAAYFAlNtL94ACgkQL6j7milTFsGZ2wCfccgyulUODofPfOr1vG98U8t+
> ujYAnjdsOnfTFsJVDeHqycRoKLkT5o/G
> =8OIw
> -END PGP SIGNATURE-
>
>
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
--
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: Slave zone intermittently not refreshing
In message , Tony Finch writes: > Mart van de Wege wrote: > > > > The only difference I *can* see is that this particular slave zone > > occasionally gets a lot of updates in a single day, which is when this > > problem seems to be triggered. > > Is there an MTU problem between your slave and the master? Or a problem > with fragmented UDP? I wonder if something is screwing up large IXFR > packets, causing your slave to get stuck - that might explain the > timeout messages in the log. > > It is a bit difficult to properly test IXFR because dig will only do it > over TCP (it ignores the +notcp option for AXFR and IXFR). And you can't > force named to use TCP for IXFR, so getting named and dig to behave the > same is tricky... 2275. [func] Add support to dig to perform IXFR queries over UDP. [RT #17235] DiG has supported ixfr over udp since 2007. It just defaults to TCP. you have to disable TCP after specifying ixfr. e.g. dig ixfr=2007111878 dv.isc.org +notcp > You could try setting "request-ixfr no;" to see if AXFR (over TCP) works > better. > > Tony. > -- > f.anthony.n.finchhttp://dotat.at/ > Shannon: Northwest 5 to 7, decreasing 4 or 5. Rough. Showers, squally at > first. Good. > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- 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: isc domain lookup
Someone trying to block isc.org/any queries in a firewall to prevent their servers being used in a amplification attack and causing collateral damage through a badly designed rule. Mark In message , Yossi Eskenazi writes: > > Hello, > > My question is not directly related to bind, but since it's related to isc > I decided to ask here. > > Some name servers I perform a lookup does not respond to queries, if they > begin with "isc" > > Example server : 213.143.254.38 > Query for any domain, it responds. Sometimes it times out, but ask again , > it eventually responds. > Query for "isc.com" "isc.org" "isc.whatever.it.is" or just "isc", it times > out. > > Example server: 185.15.40.80 > Query for any domain, it says "query refused" > Query for "isc.com" "isc.org" "isc.whatever.it.is" or just "isc", it times > out. > > It's not just these two, there are other name servers behaving this way. > > What can be the reason for this? > > Thanks for your help > > Y.E. > > --001a11c2bb4c08b70a04f96256d4 > Content-Type: text/html; charset=UTF-8 > Content-Transfer-Encoding: quoted-printable > > Hello,My question is not directly rela= > ted to bind, but since it's related to isc I decided to ask here.= > Some name servers I perform a lookup does not respond t= > o queries, if they begin with "isc" > Example server : ica Neue',Arial,Helvetica,sans-serif;font-size:12px;line-height:18px">2= > 13.143.254.38 ue',Arial,Helvetica,sans-serif;font-size:12px;line-height:18px">Query f= > or any domain, it responds. Sometimes it times out, but ask again , it even= > tually responds. > ns-serif;font-size:12px;line-height:18px">Query for " /isc.com">isc.com" "http://isc.org";>isc.org&qu= > ot; "http://isc.whatever.it.is";>isc.whatever.it.is"= > ; or just "isc", =C2=A0it times out. > al,Helvetica,sans-serif;font-size:12px;line-height:18px">Example server: 18= > 5.15.40.80 sans-serif">Query for any = > domain, it says "query refused" > ns-serif;font-size:12px;line-height:18px">Query for " /isc.com">isc.com" "http://isc.org";>isc.org&qu= > ot; "http://isc.whatever.it.is";>isc.whatever.it.is"= > ; or just "isc", =C2=A0it times out. > ica,sans-serif;font-size:12px;line-height:18px"> style=3D"font-family:'Helvetica Neue',Arial,Helvetica,sans-serif;f= > ont-size:12px;line-height:18px">It's not just these two, there are othe= > r name servers behaving this way. > ns-serif;font-size:12px;line-height:18px"> =3D"font-family:'Helvetica Neue',Arial,Helvetica,sans-serif;font-si= > ze:12px;line-height:18px">What can be the reason for this? > ns-serif;font-size:12px;line-height:18px"> =3D"font-family:'Helvetica Neue',Arial,Helvetica,sans-serif;font-si= > ze:12px;line-height:18px">Thanks for your help > ns-serif;font-size:12px;line-height:18px"> =3D"font-family:'Helvetica Neue',Arial,Helvetica,sans-serif;font-si= > ze:12px;line-height:18px">Y.E. > ns-serif;font-size:12px;line-height:18px">=C2=A0 > > --001a11c2bb4c08b70a04f96256d4-- > > --===1502673652868917195== > Content-Type: text/plain; charset="us-ascii" > MIME-Version: 1.0 > Content-Transfer-Encoding: 7bit > Content-Disposition: inline > > ___ > 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 > --===1502673652868917195==-- -- 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: About the prefetch function within bind 9.10.
If there is a query in that 9 second window then named will make a query to repopulate the cache. If there is not a query then the records will expire. You only want to prefetch records that are being queried for regularly. On 18/05/2014, at 17:18, Hongyi Zhao wrote: > What do you mean by saying that "Prefetch does not cause named to ignore > TTLs"? > > I think in my case, I have set the preftch option like this: > > -- > prefetch 2 9; > -- > > This will enable the prefetching for all of the entries with the TTL larger > that 2 seconds, (in my case, the TTL is 60 seconds, so the prefetch will be > enabled for this entry). The digit 9 triggering condition for doing the > prefetching. In my case, it should mean that when 51 seconds elapsed for the > entry, i.e., 9 = 60 - 51, the bind will prefetching the record, and then the > record will have a full TTL, i.e., 60 seconds for this case again. > > Am I wrong about the meaning of the prefetching function of bind or not? > > Regards > Zhao > > > 2014-05-18 13:46 GMT+08:00 Leonard Mills : >> Taking the CNAME line in the response, please notice that the published TTL >> is 60 seconds. Prefetch does not cause named to ignore TTLs. >> >> hth, >> Len > > > > -- > Hongyi Zhao > Xinjiang Technical Institute of Physics and Chemistry > Chinese Academy of Sciences > GnuPG DSA: 0xD108493 > ___ > 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: Handling of expired RRSIG records - ise.gov
There is no DS record for ise.gov so there is no chain of trust and the answer is treated as insecure. Note "ad" is *not* set in flags of your query. ; <<>> DiG 9.11.0pre-alpha <<>> ds ise.gov ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45170 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;ise.gov. IN DS ;; AUTHORITY SECTION: gov.3463IN SOA a.usadotgov.net. nstld.verisign-grs.com. 1400670001 3600 900 1814400 3600 ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Thu May 22 00:21:37 EST 2014 ;; MSG SIZE rcvd: 109 Mark In message , Simon Waters wr ites: > Dear Bind Users, > > BIND 9 logs report: RRSIG has expired for "www.ise.gov" > And "no valid signature found" for "ise.gov A". > > Yet I can still resolve and visit the website http://ise.gov/ > > DNS recursive server has: > dnssec-validation yes; > dnssec-enable yes; > dnssec-accept-expired no; > > Inspection: > > ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.23.rc1.32.amzn1 <<>> +norec +dnssec @ns1.p > 11.dynect.net ise.gov a > ; (2 servers found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61417 > ;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 5, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags: do; udp: 4096 > ;; QUESTION SECTION: > ;ise.gov. IN A > > ;; ANSWER SECTION: > ise.gov. 60 IN A 50.19.98.143 > ise.gov. 60 IN RRSIG A 5 2 60 20140513120652 2014041 > 3120652 45468 ise.gov. VZpvQNUKY6Vt0yxytk7JzK4FGh54SImorcnbvIRKwhGp2nrrHZWgSR > fM RiYtgbD2KSUoIOoaws5uDL1FAmMbbbFbdQBioEmJeCJMLzD1FJKPDBu3 PTtmTqgj7tdEM12ev > pM1v8JwDoN/ZYGwgMxkkOebqqrMQ0ZuprfmZqrf 6Zg= > > ;; AUTHORITY SECTION: > ise.gov. 86400 IN NS ns1.p11.dynect.net. > ise.gov. 86400 IN NS ns4.p11.dynect.net. > ise.gov. 86400 IN NS ns2.p11.dynect.net. > ise.gov. 86400 IN NS ns3.p11.dynect.net. > ise.gov. 86400 IN RRSIG NS 5 2 86400 20140513120652 201 > 40413120652 45468 ise.gov. OJ6es8al+vr2hCU9IrEkIJ+Ly/XK79g/Hlp8vDCYR6qt5VrOA5 > dzC4Nq a0IOOn9Ryo38O021tlcTp9bHhC+sf02SmmbG1oBiRSbL2JaYPD0Cm5bg rLiGB9iE3lDrg > Iz++RytufcKjnloYyCYhfAUvTe5/tmSU5tP0rdes8yw 0rA= > > ;; Query time: 22 msec > ;; SERVER: 208.78.70.11#53(208.78.70.11) > ;; WHEN: Wed May 21 11:40:16 2014 > ;; MSG SIZE rcvd: 472 > > All name servers have the same expiry time for the RRSIG A record, which unle > ss I'm more confused than I realise, is about a week ago. Clocks on all mach > ines under our control are correct to the precision required (they know what > day and year it is). > > DNSviz suggests that SOA record is secure, but not A or MX for ise.gov and th > e date on the SOA RRSIG record is indeed in the future. > > How is BIND deciding it is okay to return the A and MX records, and that this > is not some sort of DNS replay attack? > > > > > > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: bind 9.10..0-P1 rndc: 'retransfer' failed: not found; other rndc commands are ok
In message <1400811069.27931.120616781.4720c...@webmail.messagingengine.com>, g rantksupp...@operamail.com writes: > I have bind 9.10.0-P1 installed, and running in a chroot. > > which named > /usr/local/bind9/sbin/named > which rndc > /usr/local/bind9/sbin/rndc > > named -v > BIND 9.10.0-P1 > > ps ax | grep named > 7110 ?Ssl0:18 /usr/local/bind9/sbin/named -t > /var/chroot/named -n 4 -S 1024 -u named -c /etc/named.conf -d 90 > > /usr/local/bind9/sbin/named-checkconf -t /var/chroot/named > /etc/named.conf > (empty) > > > All lookups are working. Transfers to slaves work as expected when I > increment zone serials and restart the server. But when I try to > initiate a retransfer using rndc, the 'retransfer' command isn't found: No it isn't. It is saying the zone isn't found. "unknown command" is returned for unknown commands. rndc: 'x' failed: unknown command Mark > rndc status > version: 9.10.0-P1 (not disclosed) > boot time: Fri, 23 May 2014 01:10:39 GMT > last configured: Fri, 23 May 2014 01:48:35 GMT > CPUs found: 4 > worker threads: 4 > UDP listeners per interface: 2 > number of zones: 235 > debug level: 90 > xfers running: 0 > xfers deferred: 0 > soa queries in progress: 0 > query logging is ON > recursive clients: 0/0/1000 > tcp clients: 0/100 > server is up and running > > rndc -V reload my.localzone.net in external > create memory context > create socket manager > create task manager > create task > create logging context > setting log tag > creating log channel > enabling log channel > create parser > get default key > get config key list > decode base64 secret > reload > post event > using server 127.0.0.1 (127.0.0.1#953) > create socket > bind socket > connect > create message > render message > schedule recv > send message > parse message > create message > render message > schedule recv > send message > parse message > zone reload up-to-date > > rndc -V retransfer my.localzone.net in external > create memory context > create socket manager > create task manager > create task > create logging context > setting log tag > creating log channel > enabling log channel > create parser > get default key > get config key list > decode base64 secret > retransfer > post event > using server 127.0.0.1 (127.0.0.1#953) > create socket > bind socket > connect > create message > render message > schedule recv > send message > parse message > create message > render message > schedule recv > send message > parse message > rndc: 'retransfer' failed: not found > > I've looked around online, and 'retransfer' seems to still be a valid > command. > > What's wrong with my usage of retransfer? > > Grant > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: bind 9.10..0-P1 rndc: 'retransfer' failed: not found; other rndc commands are ok
In message <1400812816.1479.120623529.6c6af...@webmail.messagingengine.com>, gr antksupp...@operamail.com writes: > > > No it isn't. It is saying the zone isn't found. "unknown command" is > > returned for unknown commands. > > > > rndc: 'x' failed: unknown command > > Ok, but the zone IS there. > > It's found by other rndc commands. > > It's loaded by bind on start. > > It's transferred to slaves, again on (re)start. > > Why isn't it finding the zone? Presumably it is not a slave or a stub. retransfer is only applicable to slave and stub zones. > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: TSIG afxr failed while receiving responses: REFUSED
I suggest that you stop obfuscating the details. Errors like this are
almost always in the details. Hide the secret ('x' it out) but nothing
else. The spelling of key names is important (they must match exactly)
as are the IP addresses.
Did you reload both servers after updating them. Did you update
the correct instances of named.conf. It is easy to update the wrong
instance when you are using chroot (-t).
Mark
In message <87ppj19a7l@muck.riseup.net>, micah writes:
>
>
> Hi,
>
> I've been struggling to get TSIG setup for securing the AXFR of my zone
> transfers from the master to the secondaries. I've tried what feels like
> everything I can think of, but I am still unable to get it to work
> right. I must be missing something, and I hope that the bind community
> can tell me what it is.
>
> I'm using the new 9.10 version of bind, so I created the tsig file on
> the master by doing tsig-keygen > /etc/bind/tsig.keys, it looks like
> this:
>
> key "tsig-key" {
> algorithm hmac-sha256;
> secret "weeetsigblobhere=";
> };
>
> my named.conf has:
>
> include "/etc/bind/rndc.key";
> include "/etc/bind/tsig.keys";
> include "/etc/bind/named.conf.options";
> include "/etc/bind/named.conf.local";
> include "/etc/bind/named.conf.default-zones";
>
> and my named.conf.options has:
>
> zone "example.net" {
> type master;
> allow-transfer { key tsig.key.; };
> also-notify { ip.address.here.x; };
> file "/etc/bind/master/db.example";
> auto-dnssec maintain;
> inline-signing yes;
> };
>
> on the slave I have copied over the tsig.keys file and added to the
> bottom of it:
>
> key "tsig-key" {
> algorithm hmac-sha256;
> secret "weeetsigblobhere=";
> };
>
> server ip.of.master.here {
> keys { "tsig-key"; };
> };
>
>
> now when I try to do a zone transfer:
>
> root@owl:/etc/bind# rndc retransfer example.net
> 21-May-2014 09:34:11.828 received control channel command 'retransfer example
> .net'
> 21-May-2014 09:34:11.907 zone example.net/IN: Transfer started.
> 21-May-2014 09:34:11.987 transfer of 'example.net/IN' from ip.address.of.mast
> er#53: connected using ip.address.of.slave#48600
> 21-May-2014 09:34:12.068 transfer of 'example.net/IN' from ip.address.of.mast
> er#53: failed while receiving responses: REFUSED
> 21-May-2014 09:34:12.068 transfer of 'example.net/IN' from ip.address.of.mast
> er#53: Transfer completed: 0 messages, 0 records, 0 bytes, 0.080 secs (0 byte
> s/sec)
>
> and I see on the master:
>
> 21-May-2014 16:34:12.031 client ip.address.of.slave#48600/key tsig-key (examp
> le.net): zone transfer example.net/AXFR/IN' denied
>
> What am I missing?
>
> thanks!
> micah
>
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: TSIG afxr failed while receiving responses: REFUSED
In message <538274b9.6070...@ripe.net>, Anand Buddhdev writes:
> On 25/05/2014 16:58, micah wrote:
>
> > zone "example.net" {
> > type master;
> > allow-transfer { key tsig.key.; };
>
> Here's your mistake. You've written tsig.key, whereas your key is called
> tsig-key. Those names don't match.
Actually that isn't the mistake as they are both run through
dns_name_fromtext which will normalise them before comparison.
We don't know what the mistake is as all the details required to
determin where the error is have been changed.
> > also-notify { ip.address.here.x; };
> > file "/etc/bind/master/db.example";
> > auto-dnssec maintain;
> > inline-signing yes;
> > };
> >
> > on the slave I have copied over the tsig.keys file and added to the
> > bottom of it:
> >
> > key "tsig-key" {
> > algorithm hmac-sha256;
> > secret "weeetsigblobhere=";
> > };
> >
> > server ip.of.master.here {
> > keys { "tsig-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
--
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: TSIG afxr failed while receiving responses: REFUSED
In message <5382eb30.6040...@ripe.net>, Anand Buddhdev writes: > On 26/05/2014 01:53, Mark Andrews wrote: > > Hi Mark, > > > Actually that isn't the mistake as they are both run through > > dns_name_fromtext which will normalise them before comparison. > > I didn't know that. Does this mean that dots and dashes are equivalent > or irrelevant in tisg key names? No. Dots and dashes are not interchangable. I missed that difference. I was referring to "tsig.key." is the absolute form of "tsig.key" but given "tsig.key" is relative to "." they become equal and thus interchangable. And no this sort of error is not checkable by named-checkconf as the key could refer to a SIG(0) key. Obfuscating makes everything suspect and makes it harder to spot errors. This is a classic example. Mark > Regards, > Anand -- 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: KSK signing all records; NSEC3 algorithm status?
or > the ZSK, if inline-signing sees such a situation with no ZSK using > algorithm X, then it will sign the entire zone with the KSK, as > suggested by Kyle's debugging in 2012? Is this intentional? Yes. Named enforces the signing rules that every record is signed with every algorithm. When you add a new DNSKEY algorithm it will ensure that every RRset gets signed with it. It does this incrementally then updates the private type records to say that it has completed the operation so you can then add the DS records. If there isn't a ZSK for that algorithm it will use a KSK. > I can > see a rationale -- keep one consistent set of signing algorithms, > reduce potential for interop tangles. However, since IANA appears > to only have SHA-1 registered for NSEC3: ><http://www.iana.org/assignments/dnssec-nsec3-parameters/dnssec-nsec3- > parameters.xhtml> > this seems to be an unfortunate interplay. That is the NSEC3 HASH algorithm, not the DNSKEY algorithm. DNSKEY algorithms 6, 7, 8 10, 12, 13, and 14 are all NSEC3 capable. All future algorithms are supposed to be NSEC3 capable. For DNSKEY algorithms 252, 253 and 254 you need to look at the individual algorithms encoded at the start of the key field. Algorithms 1, 3, and 5 are not NSEC3 capable and their presence in the DNSKEY RRset will stop attempts to use NSEC3 with the zone. > (3) Anyone have any constructive suggestions or advice to guide me out? > Even if it's just "go route 1, at this time don't bother touching > other hash algorithms while using NSEC3"? > > Guidance appreciated, thanks, > - -Phil > -BEGIN PGP SIGNATURE- > > iQEcBAEBCAAGBQJThTt4AAoJEKBsj+IM0duFFq4IAJ+dn1+0Vkm7XnN+r70QDWmD > fgEN0G9D72TRJ0lYqkd19W/qwctfKDkCUaTt3BIjRwBDV3bQXxqLQkXxH7jWFNXK > czZEEm6mOKCQWcBEKAMtfWM5cGKGAjSjfvbA2ZOAvuUIkDfYN0s4kcWYFTre7Zyk > SSnZi909xs1ZPiuz447dmUBr3gg5wNJAuUNiNJJP9DHriu6542DdRzUtbu3zmABG > rBAjS/budz/nr3INHYvTCyR1PJ7RtzxtVT5PcnQ0GnP1H92Zspk3rDrqc8CWDSUA > 5UUV0D8qSE8xvzwcW6qiaJO7OkYoaUgxjgsS0rsceOoLWLriIZuVsV8NgT8SNMw= > =hRKl > -END PGP SIGNATURE- > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- 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
