Re: Last transfer time?
In message 20101203163608.ga47...@2bithacker.net, Chip Marshall writes: On 03-Dec-2010, Barry Margolin bar...@alum.mit.edu sent: In article mailman.913.1291323587.555.bind-us...@lists.isc.org, Chris Buxton chris.p.bux...@gmail.com wrote: On Dec 1, 2010, at 12:46 PM, Chip Marshall wrote: Just curious if there's an official and accurate way to determine the last sucessful transfer time of a slave zone from a BIND server. You can see the last successful refresh, whether it involved a zone transfer or not, by looking at the datestamp on the file. It's unclear whether the OP is trying to determine this on the slave or the master. The above solution works on the slave. Yes, it's on the slave. I was kindof hoping it would be in the per-zone statistics in the XML statistics-channel, but file mtime should be good enough for what I need. Though I might just have syslog send the named output to a script that keeps track of last transfer and some other useful stats. Thanks to everyone for your input. The mtime is the last time the slave refreshed *or* transfer the zone. If you want a definitative time for last transfer you need to look in the logs. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DS queries on parents vs. correct behaviour in answering
In message 02d001cb93f5$513ca2b0$f3b5e8...@janssen@eurid.eu, Peter Janssen writes: When a validating resolver queries the parent of a zone for the DS record(s), and the (child) zone is NOT signed, the response contains no answer but it does contain NSEC (NSEC3) record(s) in the authority section together with corresponding RRSIG records (parent zone is signed). Would it be considered ok, harmfull, not allowed, (any other word) to include in that answer the NS RRSET for the child zone (obviously without any RRSIG)? Against RFC? Not specified? Would it break resolvers? Any or all implementations? What do you think? The server is broken. The DS records are part of the parent zone and the authority section should reflect that. DNSSEC unaware parent servers return referrals to the child zone. A resolver see such a referral is likely to just drop the response and move on to the next server. I suspect you are asking this because of x.dns.be's answers. Note the anwer is also missing the SOA record required for negative caching (RFC 2308). Mark ; DiG 9.6.0-APPLE-P2 foo.be +dnssec @x.dns.be +norec ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 40730 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;foo.be.IN A ;; AUTHORITY SECTION: foo.be. 86400 IN NS ns6.gandi.net. foo.be. 86400 IN NS ka.quuxlabs.com. ba141snrnoe1rc9mddgrest23g657rir.be. 600 IN NSEC3 1 1 5 1A4E9B6C BB7ONI6L9S8J5E3K6HUQ7C41J1AN85CR NS SOA RRSIG DNSKEY NSEC3PARAM TYPE65534 ba141snrnoe1rc9mddgrest23g657rir.be. 600 IN RRSIG NSEC3 8 2 600 20101207140244 20101130135115 61344 be. ZzvHV36wtbQ9woSfpc6nltz+tPc9GStoiEj4Fux+w70xkroPgjCtXhoY jC1uErBEAIKVoMKijb4TbFkssppxTZPvsqqYO3nE6ANWm85pHpP/q9VI eMk8RKcopptowjT9opikpvOJnOxlq3zTWBBoUjpyc6ZhJAPun3RPbQg5 Lfw= 040gpts32ds6q6unjgf8eh7bpal1m1ik.be. 600 IN NSEC3 1 1 5 1A4E9B6C 06JFHM0ATMQQJ2C08HOFHCO313VOSEEG NS DS RRSIG 040gpts32ds6q6unjgf8eh7bpal1m1ik.be. 600 IN RRSIG NSEC3 8 2 600 20101207152009 20101130151117 61344 be. Rk1cwdoDfSo99pNPyBzducYv3CRa4qh3fpQmJifDWCxnR3WIAElwaqrV dh9czL06jPBBGFTJLzSYs+jbxmrt/iK3EE7E/0Z+AJiZTMBhO+LOY2YM U2sU9SX7/cZvtKvIN73/HI1VegcNrDFCqrJvU9zsaUmDwynLGqolzWBV tGI= ;; Query time: 483 msec ;; SERVER: 2001:678:4::a#53(2001:678:4::a) ;; WHEN: Sun Dec 5 09:00:21 2010 ;; MSG SIZE rcvd: 620 Thanks. --Pj. =A0=A0=A0 = Register your .eu domain name and win an iPod touch this X-Mas http://www.winwith.eu ___ 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 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DS queries on parents vs. correct behaviour in answering
Mark Andrews writes: In message 02d001cb93f5$513ca2b0$f3b5e8...@janssen@eurid.eu, Peter Janssen writes: When a validating resolver queries the parent of a zone for the DS record(s), and the (child) zone is NOT signed, the response contains no answer but it does contain NSEC (NSEC3) record(s) in the authority section together with corresponding RRSIG records (parent zone is signed). Would it be considered ok, harmfull, not allowed, (any other word) to include in that answer the NS RRSET for the child zone (obviously without any RRSIG)? Against RFC? Not specified? Would it break resolvers? Any or all implementations? What do you think? The server is broken. The DS records are part of the parent zone and the authority section should reflect that. DNSSEC unaware parent servers return referrals to the child zone. A resolver see such a referral is likely to just drop the response and move on to the next server. I suspect you are asking this because of x.dns.be's answers. Note the anwer is also missing the SOA record required for negative caching (RFC 2308). Mark It helps if I have the right type in the question. ; DiG 9.6.0-APPLE-P2 foo.be +dnssec @x.dns.be +norec ds ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 37780 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;foo.be.IN DS ;; AUTHORITY SECTION: foo.be. 86400 IN NS ns6.gandi.net. foo.be. 86400 IN NS ka.quuxlabs.com. ba141snrnoe1rc9mddgrest23g657rir.be. 600 IN NSEC3 1 1 5 1A4E9B6C BB7ONI6L9S8J5E3K6HUQ7C41J1AN85CR NS SOA RRSIG DNSKEY NSEC3PARAM TYPE65534 ba141snrnoe1rc9mddgrest23g657rir.be. 600 IN RRSIG NSEC3 8 2 600 20101207140244 20101130135115 61344 be. ZzvHV36wtbQ9woSfpc6nltz+tPc9GStoiEj4Fux+w70xkroPgjCtXhoY jC1uErBEAIKVoMKijb4TbFkssppxTZPvsqqYO3nE6ANWm85pHpP/q9VI eMk8RKcopptowjT9opikpvOJnOxlq3zTWBBoUjpyc6ZhJAPun3RPbQg5 Lfw= 040gpts32ds6q6unjgf8eh7bpal1m1ik.be. 600 IN NSEC3 1 1 5 1A4E9B6C 06JFHM0ATMQQJ2C08HOFHCO313VOSEEG NS DS RRSIG 040gpts32ds6q6unjgf8eh7bpal1m1ik.be. 600 IN RRSIG NSEC3 8 2 600 20101207152009 20101130151117 61344 be. Rk1cwdoDfSo99pNPyBzducYv3CRa4qh3fpQmJifDWCxnR3WIAElwaqrV dh9czL06jPBBGFTJLzSYs+jbxmrt/iK3EE7E/0Z+AJiZTMBhO+LOY2YM U2sU9SX7/cZvtKvIN73/HI1VegcNrDFCqrJvU9zsaUmDwynLGqolzWBV tGI= ;; Query time: 483 msec ;; SERVER: 2001:678:4::a#53(2001:678:4::a) ;; WHEN: Sun Dec 5 09:06:10 2010 ;; MSG SIZE rcvd: 620 ; DiG 9.6.0-APPLE-P2 foo.be +dnssec @x.dns.be +norec ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 40730 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;foo.be. IN A ;; AUTHORITY SECTION: foo.be. 86400 IN NS ns6.gandi.net. foo.be. 86400 IN NS ka.quuxlabs.com. ba141snrnoe1rc9mddgrest23g657rir.be. 600 IN NSEC3 1 1 5 1A4E9B6C BB7ONI6L9S8J 5E3K6HUQ7C41J1AN85CR NS SOA RRSIG DNSKEY NSEC3PARAM TYPE65534 ba141snrnoe1rc9mddgrest23g657rir.be. 600 IN RRSIG NSEC3 8 2 600 2010120714024 4 20101130135115 61344 be. ZzvHV36wtbQ9woSfpc6nltz+tPc9GStoiEj4Fux+w70xkroPgj CtXhoY jC1uErBEAIKVoMKijb4TbFkssppxTZPvsqqYO3nE6ANWm85pHpP/q9VI eMk8RKcopptow jT9opikpvOJnOxlq3zTWBBoUjpyc6ZhJAPun3RPbQg5 Lfw= 040gpts32ds6q6unjgf8eh7bpal1m1ik.be. 600 IN NSEC3 1 1 5 1A4E9B6C 06JFHM0ATMQQ J2C08HOFHCO313VOSEEG NS DS RRSIG 040gpts32ds6q6unjgf8eh7bpal1m1ik.be. 600 IN RRSIG NSEC3 8 2 600 2010120715200 9 20101130151117 61344 be. Rk1cwdoDfSo99pNPyBzducYv3CRa4qh3fpQmJifDWCxnR3WIAE lwaqrV dh9czL06jPBBGFTJLzSYs+jbxmrt/iK3EE7E/0Z+AJiZTMBhO+LOY2YM U2sU9SX7/cZvt KvIN73/HI1VegcNrDFCqrJvU9zsaUmDwynLGqolzWBV tGI= ;; Query time: 483 msec ;; SERVER: 2001:678:4::a#53(2001:678:4::a) ;; WHEN: Sun Dec 5 09:00:21 2010 ;; MSG SIZE rcvd: 620 Thanks. --Pj. =A0=A0=A0 = Register your .eu domain name and win an iPod touch this X-Mas http://www.winwith.eu ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: bind9 cache
In message 20101204170822.94482eupddwii...@www.jersore.net, Benny Pedersen wr ites: i like to have bind cache in 43200 secs for any zone and update only if soa changes in that time, how do i configure named.conf to do this ? You can set a maximum bound on how long named will cache records for (max-cache-ttl) however named will not go out and look to see if the SOA has change nor will named cache for longer than the TTL permits. negative cache i like to have as the zone says in ttl, so just 43200 on positive -- xpoint ___ 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 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: can't validate existing negative responses (not a zone cut) messages
In message prayer.1.3.3.1012061052110.14...@hermes-2.csi.cam.ac.uk, Chris Tho mpson writes: On Oct 3 2010, I wrote: Since upgrading our main recursive nameservers to BIND 9.7.2-P2 (and using a trust anchor for the root and lookaside via dlv.isc.org) I am seeing a scatter of warning messages like this: Oct 1 19:47:19 dnssec: warning: validating @1c29d580: 115.197.101.95.IN-ADDR.ARPA PTR: can't validate existing negative responses (not a zone cut) [...] What do they mean, exactly? And should I be worrying about them? They all seem to refer to PTR records (not all of them for IP addresses in 95.101/16, but many of them are). There were some followups, but we never got anything from ISC. After upgrading to BIND 9.7.2-P3, they appear to have gone away, so I presume one of the changes (maybe 2970) has fixed them. It would be part of change 2968. 2968. [security] Named could fail to prove a data set was insecure before marking it as insecure. One set of conditions that can trigger this occurs naturally when rolling DNSKEY algorithms. CVE-2010-3614, VU#837744. [RT #22309] Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Troubleshooting slow DNS lookup
In message aanlkti=t5tj29_gmngbtpug8cfyrqpgadr=-yvfwj...@mail.gmail.com, Rian to Wahyudi writes: Our network team are quite reluctant to make any changes on the FWSM in regards to DNS inspection. So it seems that we are stuck with maximum UDP packet of 512 byte. Unfortunately, I do not have much evidence (ie user complains) to escalate this issue much further except from few number of users who *intermittently* unable to access www.paypal.com. The term intermittently is the main keyword, and because of that the finger are now point back the the DNS server. It's intermittent because it takes named time to workout what will work with your firewall and the clients timeout in the meantime. This will only get worse over time. I believe that Increasing the maximum limit or disable inspection will fix the issue , but I will need to gather sufficient case and compelling report. Standards Track. RFC 2671 Extension Mechanisms for DNS (EDNS0) RFC 3226 DNSSEC and IPv6 A6 aware server/resolver message size requirements Informational. RFC 4294 IPv6 Node Requirements http://labs.ripe.net/Members/anandb/content-testing-your-resolver-dns-reply-size-issues - Does any one have a good example of prominent website that have DNSEC setup properly other than paypal? How about the root servers? - Any example of dns record that send packet larger than 512 ? The root servers. dig +dnssec dnskey . - Any other information I can use to help create the report ? As a work around I can possibly set EDNS UDP size to match the firewall limit, but I think this is my last option. Any help is greatly appreciated! Regards, Rianto Wahyudi ___ 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 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Troubleshooting slow DNS lookup
In message aanlktims2mfbib5lpdpqyarc8ds1gg4db7b2tea=b...@mail.gmail.com, Rian to Wahyudi writes: Hi Mark, Thanks for your quick response ! Standards Track. RFC 2671 Extension Mechanisms for DNS (EDNS0) RFC 3226 DNSSEC and IPv6 A6 aware server/resolver message size requiremen= ts Unfortunately RFC is not considered as good enough ... unless if we can find an actual proof that can be replicated :( I also done some dnssec trace demonstration, and it still not a good enough reason : ie : dig www.anyhostname.com +trace +dnssec . This test always fail and it produce FWSM log entry similar to: : %FWSM-2-106007: Deny inbound UDP from 198.142.0.51/53 to 10.0.0.1/64788 due to DNS Response I also suggest that you ask your firewall people to talk to the CISCO TAC about how to properly configure the firewall for a nameserver that supports EDNS. The defaults are not setup for a nameserver that supports EDNS. If they don't want to do that read what CISCO recommends here: https://supportforums.cisco.com/message/3221565#3221565 Informational. RFC 4294 IPv6 Node Requirements http://labs.ripe.net/Members/anandb/content-testing-your-resolver-dns-rep= ly-size-issues How about the root servers? - Any example of dns record that send packet larger than 512 ? The root servers. =A0 =A0 =A0 =A0dig +dnssec dnskey . This for some reason works without any problem : Well if you ask the root servers dig +dnssec dnskey . @a.root-servers.net With just dig +dnssec dnskey . you are talking to your own server so are not going through the firewall. You will also notice it took 1/2 a second to get that answer so named did several different attempts in that 1/2 second. ;; Query time: 547 msec -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Unusual TSIG problem
In message 20101208214221.566771c...@ptavv.es.net, Kevin Oberman writes: I just ran into an odd issue with a TSIG signed zone transfer. On occasion I was logging a clocks are unsynchronized message doing a transfer from a customer server at a site about 30 ms away. I dropped a note to the manager there asking that he look at the his system for a time issue. He checked and found no problems. Today I looked at the problem more closely. I realized that the problem was NOT a clock sync issue. They were probably within a millisecond of one another. I found the following in the log: Dec 8 06:26:18 ns1 named[67170]: zone XX.gov/IN: notify from 123.234.1.1 #33372: refresh in progress, refresh check queued Dec 8 06:31:18 ns1 named[67170]: transfer of 'XX.gov/IN' from 123.234.1. 1#53: failed while receiving responses: clocks are unsynchronized Dec 8 06:31:18 ns1 named[67170]: transfer of 'XX.gov/IN' from 123.234.1. 1#53: Transfer completed: 1 messages, 397 records, 59674 bytes, 898.462 secs (66 bytes/sec) The transfer, probably due to a hardware problem was taking over 5 minutes to transfer the zone and RFC2845 suggests tha the difference between clocks should be limited to 300 seconds (5 minutes). This really means that, should the transfer take over 5 minutes, you get the unsynced clocks error. (4.5.2. TIME check and error handling) 59674*8/397 = 1202 b/s that's slower than almost all dialup lines. If this happens regularly use transfer-format multiple-messages which results in smaller messages and more signatures. Clearly, something is broken when a zone transfer takes over 5 minutes. (This one SHOULD take about 2-3 seconds.) But the message certainly pointed in the wrong direction. Is there more appropriate language that might indicate that it could also be an effective time-out because the transfer took too long? Maybe failed while receiving responses: clocks are unsynchronized or maximum transfer time exceeded? -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.netPhone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ 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 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: bind autosign - DS distribution
In message 20101209222644.ga2...@fantomas.sk, Matus UHLAR - fantomas writes: In message 20101209220716.ga2...@fantomas.sk, Matus UHLAR - fantomas writ es: pardon my ignorance if this has been discussed (haven't notice), but if BIND is configured to automatically sign dynamic zones, does it distribute DS records to parent zones somehow? and if not, what are ways to do that? On 10.12.10 09:15, Mark Andrews wrote: This is IETF dnsext/dnsop fodder. The simple way would be to just record a TSIG key in the child zones config to update the parent zone and use signed UPDATE messages. Unfortunately this has run into layer 9 issues. maybe some alternative of NOTIFY mechanism? However that's apparently why I missed it... I think I'll try with opendnssec. I even don't like the automatic mechanism much because of bulk updates which I do quite often. Is it possible(planned) for bind to sign slave zone? The master signs the zone. The slaves just serve it. And, are incremental updates possible with dnssec? Yes. You just send the signature and nsec/nsec3 changes as well as the data changes themselves. I'm thinking about hidden master bind loading (un)signed zones and providing axfr/ixfr to our public servers DNSSEC works with hidden masters. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DiG 9.3.6-P1 segfaults on CentOS
In message b4fd91b6-c9da-47db-88bf-7f9af7883...@smtps.net, Brian Keefer write s: Downloading the tarball for bind-9.7.2-P1 from ftp.isc.org and building it fr om source fixed the segfault issue. I'm still seeing a (possibly related) issue where if I do dig +trace txt dns bl record it takes 6-10 seconds (measured by time(1)) to complete, all after printing the authoritative server for DNSBL (prior to printing answer). If I do dig @dnsbl.hostname txt dnsbl record I get the same pause. If I d o dig @dnsbl IP txt dnsbl record there is no pause. There is also no pau se if I do dig dnsbl.hostname. It doesn't look like there's any issue reso lving the A RR, so why the long pause with dig +trace or dig @hostname vs. di g @IP? And if you look for IPv6 addresses? dig dnsbl.hostname I'm only getting this behavior with this particular DNSBL, so far as I know. The DNSBL runs a modified (only the back-end, SFAIK) version of rbldnsd. -- bk ___ 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 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: forwarding
Firstly please get a sane email client. Printed quotable is supposed to
be readable by old mail clients. Your client is turning the line breaks
you entered into =A0 rather than preserving.
Secondly the default for allow-recursion is {localhost; localnets;}.
The clients that you are having problems with do not match this acl.
Mark
In message 437749.18198...@web55604.mail.re4.yahoo.com, Ed Arizona writes:
=0A=0AWe're seeing an issue with regarding to a bind9 server setup as a 'fo=
rward only' =0Asystem.=A0 =0A=0A=0AThe server is multihomed on five unique =
subnets.=A0 Any host local to any of those =0Asubnets can use this server t=
o properly resolve the zone served.=A0 Any host =0Aoutside of the local sub=
nets, cannot.=0A=0ARouting is properly set up and hosts on various remote s=
ubnets can reach the dns =0Aserver on port 53.=0A=0AWhen we downrev to bind=
8 using the same named.conf configuration file, the issue =0Adisappears.=A0=
Is this is a known issue?=A0 Is there a configuration item I'm not =0Aawar=
e of that I need to set or unset?=0A=0AThanks, Colin=0A=0A=0A
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Silently drop queries for AAAA records
In message 4d06a75f.7080...@chrysler.com, Kevin Darcy writes: On 12/7/2010 5:31 PM, David A. Evans wrote: I'm in the mood to prove a point. I have a very poorly written application that is generating a few hundred queries per second of completely bogus records before attempting a lookup of the correct A records. This is because the application was compiled with a IPv6 interface enabled on the severs so it assumes that v6 is available. It is not. The application owner does not see an issue as they get the handful NXDOMAIN responses back in ~2 ms for each valid response and don't see any performance hit. I would like to silently drop the record lookups instead of responding back with NXDOMAIN. NXDOMAIN? Is the application looking up a different *name* for its queries than for its A queries? If a single name owned A records but no records then the correct response from an -capable resolver to an query of the name, would be the so-called NODATA response (NOERROR with 0 answers and an SOA RR in Authority Section for negative caching purposes, see RFC 2308 for details). NXDOMAIN, as another poster pointed out, could inhibit even A-record queries of the name, and would be the wrong response in that situation. It's likely to be applying the search list to queries and *not* stopping on NODATA then applying the search list to A queries. I've argued that this is wrong behaviour and that searches should stop on NODATA but some people are worried that this change in behaviour will break something that is depending on the searches skipping NODATA responses. If you are worried about this then complain to the OS vendor to fix the resolver library. Thusly generating a performance hit as the application waits 2 seconds for the reply. I have found the filter--on-v4 but it doesn't quiet do what I want. From the description and my testing it appears to still reply with NXDOMAIN to these queries, it simply filters out the 'valid' records from IPV4 based replies. (which is a really cool solution to other issues, but not what I need.) How nasty do you want to be? You could always add an record for that name. Point it anywhere you want evil laugh If you point it to something simply non-existent, this solution seems to me only slightly ruder than silently dropping the queries. Besides spinning up a bind 4.x box which google tells me did this by default, is there any way of doing this? BIND 4 did not block queries. I think it would be a really *bad* idea to spin up a BIND 4.x instance. Do you really want a big ugly security hole on your network? What about the person that inherits this setup from you? Would they be conversant in BIND 4.x setup and maintenance? I wouldn't wish BIND 4.x on anyone... If you really want to go in the direction of dropping packets, I'd look at some sort of software-firewall intervention (iptables or whatever) to do the packet-dropping. On the other hand, if the app really is looking up a different name for than for A (see above), that opens up all sorts of options for you. You could set up that name as a zone by itself and simply return REFUSED for all of those queries (the response packet count, and potentially the application delay, would be the same, but the response packets would be smaller and your intent crystal clear). Or set up a forwarder and play some games that way. Or stop worrying about this and realise that it will self correct as more sites start using IPv6 and records. IPv4 really has passed its use by date. - Kevin -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Strange behaviour of dnssec-signzone
In message c008a6086493ca91d9b6707551689...@[::1], Patrick Vande Walle writes : Greetings, My zone file contains a TXT record for DKIM : sig-2010._domainkey IN TXT v=DKIM1; r=postmaster; g=*; k=rsa; t=s; p=[deleted for shortness] When I run: /usr/sbin/dnssec-signzone -u -3 5D2CA8 -C -g -p -o example.net. -e +7776000 -l dlv.isc.org zone.db K*.private 21 It returns: dnssec-signzone: fatal: failed loading zone from 'zone.db': ran out of space If I delete the g=*; tag of the TXT record sig-2010._domainkey IN TXT v=DKIM1; r=postmaster; k=rsa; t=s; p=[deleted for shortness] A string in a TXT record can only be 255 characters long though there can be multiple strings. If you try to load a string longer than 255 characters you will get the error above. RFC 4871 DomainKeys Identified Mail (DKIM) Signatures Strings in a TXT RR MUST be concatenated together before use with no intervening whitespace. TXT RRs MUST be unique for a particular selector name; that is, if there are multiple records in an RRset, the results are undefined. signing happens with no problem. I am wondering if others have seen this strange behaviour of dnssec-signzone (version 9.7.1-P2). Thanks, Patrick Vande Walle ___ 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 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9 and IDN
In message 280913e87fd58a4fbceef62d9d0477d35542449...@vmail.vermeermfg.com, Ha ll, David writes: Is there any expertise on implementing Bind and IDN? Our business is wanti ng to server up DNS for an IDN. I have attempted to add what I believe is needed - but can not do a nslookup or a query from external website for thi s new domain. Are there any additional steps need to have a IDN? Thanks in advance. Dave H You need to turn on IDN support at compile time if you want the lookup tools to do the name conversions prior to looking up the data in the DNS. --with-idn=MPREFIX enable IDN support using idnkit default PREFIX --with-libiconv=IPREFIX GNU libiconv are in IPREFIX default PREFIX --with-iconv=LIBSPECspecify iconv library default -liconv --with-idnlib=ARG specify libidnkit As far as named is concerned these are just regular domain names that start with xn--. All the IDN knowledge is outside of named. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
BIND 9.8.0a1
Introduction BIND 9.8.0a1 is the first alpha release of BIND 9.8. This document summarizes changes from BIND 9.7 to BIND 9.8. Please see the CHANGES file in the source code release for a complete list of all changes. Download The latest release of BIND 9 software can always be found on our web site at http://www.isc.org/software/bind. There you will find additional information about each release, source code, and some pre-compiled versions for certain operating systems. Support Product support information is available on http://www.isc.org/services/support for paid support options. Free support is provided by our user community via a mailing list. Information on all public email lists is available at https://lists.isc.org/mailman/listinfo. New Features 9.8.0 * BIND 9.8.0 now has partial DNS64 support (we synthesize records). [RT #21991] Feature Changes 9.8.0 * There is a new option in dig, +onesoa, that allows the final SOA record in an AXFR response to be suppressed. [RT #20929 * There is additional information displayed in the recursing log (qtype, qclass, qid and whether we are following the original name). [RT #22043] Security Fixes 9.8.0 None. Bug Fixes 9.8.0 * For Mac OS X, you can now have the test interfaces used during make test stay beyond reboot. See bin/tests/system/README for details. * Failure to read OpenSSL configuration file does not cause BIND utilities such as dig to fail. [RT #20668] * nsupdate will now preserve the entered case of domain names in update requests it sends. [RT #20928] Known issues in this release * None. Thank You Thank you to everyone who assisted us in making this release possible. If you would like to contribute to ISC to assist us in continuing to make quality open source software, please visit our donations page at http://www.isc.org/supportisc. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: dnssec-lookaside != auto
In message 4d0f00dd.9060...@data.pl, Torinthiel writes:
On 12/20/10 01:32, Mark Andrews wrote:
In message 4d0e8340.9060...@data.pl, Torinthiel writes:
Hello everyone,
I've recently updated bind to version 9.7.2_p3.
Upgraded from what?
From 9.4.3_p5
I've been using DLV before that, specifically dlv.isc.org, with two
entries in named.conf
options {
dnssec-lookaside . trust-anchor dlv.isc.org.;
};
trusted-keys{
[sometext]
};
and it was working fine.
However, on update I've wanted to try managed-keys. so changed
trusted-keys to managed-keys (and added initial key of course)
so the relevant part of config file now looks like this:
managed-keys {
dlv.isc.org. initial-key 257 3 5
BEPHMu/5onzrEE7z1egmhg/WPO0+juoZrW3euWEn4MxDCE1+lLy2
brhQv5rN32RKtMzX6Mj70jdzeND4XknW58dnJNPCxn8+jAGl2FZLK8t+
1uq4W+nnA3qO2+DL+k6BD4mewMLbIYFwe0PG73Te9fZ2kJb56dhgMde5
ymX4BI/oQ+cAK50/xvJv00Frf8kw6ucMTwFlgPe+jnGxPPEmHAte/URk
Y62ZfkLoBAADLHQ9IrS2tryAe7mbBZVcOwIeU/Rw/mRx/vwwMCTgNboM
QKtUdvNXDrYJDSHZws3xiRXF1Rf+al9UmZfSav/4NWLKjHzpT59k/VSt TDN0YUuWrBNh;
};
this has caused problem, every query caused error, no answers and these
log entries:
Dec 19 21:22:38 sarlac named[4137]: validating @0xb48c0030: dlv.isc.org
DNSKEY: must be secure failure, . is under DLV (startfinddlvsep)
Dec 19 21:22:38 sarlac named[4137]: error (must-be-secure) resolving
'dlv.isc.org/DNSKEY/IN': 156.154.101.23#53
And what other errors were logged by named when it started?
None. Complete startup log sequence:
Dec 20 07:49:14 sarlac named[4137]: loading configuration from
'/etc/bind/named.conf'
Dec 20 07:49:14 sarlac named[4137]: reading built-in trusted keys from
file '/etc/bind/bind.keys'
Dec 20 07:49:14 sarlac named[4137]: using default UDP/IPv4 port range:
[1024, 65535]
Dec 20 07:49:14 sarlac named[4137]: using default UDP/IPv6 port range:
[1024, 65535]
Dec 20 07:49:14 sarlac named[4137]: set up managed keys zone for view
_default, file 'managed-keys.bind'
Dec 20 07:49:14 sarlac named[4137]: reloading configuration succeeded
Dec 20 07:49:15 sarlac named[4137]: managed-keys-zone ./IN: loaded serial 16
Dec 20 07:49:15 sarlac named[4137]: zone torinthiel.pl/IN: loaded serial
2010110801
Dec 20 07:49:15 sarlac named[4137]: reloading zones succeeded
Dec 20 07:49:15 sarlac named[4137]: zone torinthiel.pl/IN: sending
notifies (serial 2010110801)
After some googling and finding
http://www.mail-archive.com/bind-users@lists.isc.org/msg06660.html
and even better
http://www.mail-archive.com/bind-users@lists.isc.org/msg05689.html
I've changed to dnssec-lookaside auto. Lo and behold, everything works
fine.
And the contents of /etc/bind.key are? Also the contents in the
chroot area if you are using chroot.
Changed /etc/bind.keys to /etc/bind/bind.keys, via config (and it reeds
it, you can see in logs). Contents were given in first post, only I
haven't mentioned it was in /etc/bind/bind.keys.
The managed-keys statement is the sole statement in /etc/bind/bind.keys
and is not present in main config file.
Ok, this was the problem. Having included the file as well as specified
it at bindkeys-file seems to have solved the problem. Ok, now the
documentation seems a bit unclear about it. It never states that the
file is included nor that it's not. But having information that it loads
the given file (in dnssec-lookaside description) and information that
file is loaded in logs has given me a false sense of security in this
case. Is this double-include (sort of) configuration what I was supposed
to do? Will it work correctly after a key rollover?
Including a trusted/managed-key multiple times won't hurt. It should work
correctly after key rollover.
Also, another question arises: can one include more than one
bindkeys-file and/or dnssec-lookaside in config? The documentation hints
that at least the latter is possigble, but does not state so. And having
multiple bindkeys-file is useful if you have locally-configured keys,
for which using the main file is not recommended.
Only one dnssec-lookaside clause is supported.
Multiple trusted-keys/managed keys clauses are supported.
Skipping rest of answers, as problem is (mostly) solved.
Regards,
Torinthiel
___
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
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: bind slave not get DNS update
In message 8b5c6f575422414aa91b46c454126b6c02666af...@exchmvs.exchange.airg,
Steve Zeng writes:
Tcpdump on master(A.A.A.A) shows the following:
And what source address does the slave see?
23:59:54.788272 IP A.A.A.A.domain C.C.C.C.domain: 26512 notify [b23=0x240
0] [1a] SOA? mydomain.com. (72)
23:59:54.788898 IP C.C.C.C.domain A.A.A.A.domain: 26512 notify Refused- 0/
0/0 (26)
So it looks like master did sent notify out but refused by BIND slave
also-notify {
B.B.B.B;# public IP of first DNS slave(win
dows DNS)
C.C.C.C;# public IP of second DNS slave(Li
nux BIND DNS)
};
Steve
-Original Message-
From: bind-users-bounces+stevez=airg@lists.isc.org [mailto:bind-users-bou
nces+stevez=airg@lists.isc.org] On Behalf Of Niall O'Reilly
Sent: Wednesday, January 05, 2011 3:33 PM
To: bind-users@lists.isc.org
Subject: Re: bind slave not get DNS update
On 05/01/11 01:50, Steve Zeng wrote:
I don't have NS record for both of the slaves (windows DNS slave and
Linux DNS slave). I use also-notify and it works for Windows DNS
slave. But not for BIND/Linux.
On 05/01/11 19:56, Steve Zeng wrote:
Rndc transfer (initialized at the slave side) works fine...
Good. Manual intervention works.
I suggest you try to determine the following from your logs
on both master and (Linux) slave.
Whether the master is sending the NOTIFY.
Whether the slave is receiving the NOTIFY.
Whether the slave is acting on the NOTIFY.
That should make it clear what's not happening without
manual intervention.
Best regards,
Niall O'Reilly
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
___
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
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Confused about /24 in-addr.arpa NS delegation debug problem
In message 4d26508c.7090...@gmail.com, Gary Wallis writes: (Some dig output lines deleted to keep short) Why does this not work (but below next dig with +trace seems to imply that it should?): More modern version of dig report the error BAD (HORIZONTAL) REFERRAL. If 147.95.81.in-addr.arpa is delegated to ns?.ltheplanet.com when it should be delegated to ns?.callingcloud.net. Your ISP has to update the nameserver information held by RIPE. Mark 147.95.81.in-addr.arpa. 172800 IN NS ns1.theplanet.com. 147.95.81.in-addr.arpa. 172800 IN NS ns2.theplanet.com. ;; Received 115 bytes from 2001:610:240:0:53::3#53(ns-pri.ripe.net) in 739 ms 147.95.81.in-addr.arpa. 86400 IN NS ns2.callingcloud.net. 147.95.81.in-addr.arpa. 86400 IN NS ns1.callingcloud.net. ;; BAD (HORIZONTAL) REFERRAL ;; Received 96 bytes from 207.218.223.162#53(ns2.theplanet.com) in 206 ms 100.147.95.81.in-addr.arpa. 86400 INPTR ns3.callingcloud.net. 147.95.81.in-addr.arpa. 86400 IN NS ns3.callingcloud.net. 147.95.81.in-addr.arpa. 86400 IN NS ns1.callingcloud.net. 147.95.81.in-addr.arpa. 86400 IN NS ns2.callingcloud.net. ;; Received 176 bytes from 174.121.136.100#53(ns1.callingcloud.net) in 215 ms [r...@web0 /]# dig -x 81.95.147.100 ; DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_4.2 -x 81.95.147.100 ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: SERVFAIL, id: 10895 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;100.147.95.81.in-addr.arpa.IN PTR ;; Query time: 489 msec ;; SERVER: 8.8.4.4#53(8.8.4.4) ;; WHEN: Fri Jan 7 02:20:28 2011 ;; MSG SIZE rcvd: 44 But this returns the PTR: (WTF?) [r...@web0 /]# dig -x 81.95.147.100 +trace ; DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_4.2 -x 81.95.147.100 +trace ;; global options: printcmd . 80166 IN NS j.root-servers.net. . 80166 IN NS i.root-servers.net. ...snip . 80166 IN NS b.root-servers.net. ;; Received 228 bytes from 8.8.8.8#53(8.8.8.8) in 83 ms arpa. 172800 IN NS f.root-servers.net. arpa. 172800 IN NS b.root-servers.net. ...snip arpa. 172800 IN NS e.root-servers.net. ;; Received 508 bytes from 192.58.128.30#53(j.root-servers.net) in 165 ms 81.in-addr.arpa.86400 IN NS SEC1.APNIC.NET. 81.in-addr.arpa.86400 IN NS SEC3.APNIC.NET. 81.in-addr.arpa.86400 IN NS NS3.NIC.FR. 81.in-addr.arpa.86400 IN NS NS-PRI.RIPE.NET. 81.in-addr.arpa.86400 IN NS TINNIE.ARIN.NET. 81.in-addr.arpa.86400 IN NS SNS-PB.ISC.ORG. 81.in-addr.arpa.86400 IN NS SUNIC.SUNET.SE. ;; Received 223 bytes from 192.5.5.241#53(f.root-servers.net) in 166 ms 147.95.81.in-addr.arpa. 172800 IN NS ns1.theplanet.com. 147.95.81.in-addr.arpa. 172800 IN NS ns2.theplanet.com. ;; Received 93 bytes from 202.12.29.59#53(SEC1.APNIC.NET) in 317 ms 147.95.81.in-addr.arpa. 86400 IN NS ns2.callingcloud.net. 147.95.81.in-addr.arpa. 86400 IN NS ns1.callingcloud.net. ;; Received 96 bytes from 207.218.247.135#53(ns1.theplanet.com) in 106 ms 100.147.95.81.in-addr.arpa. 86400 INPTR ns3.callingcloud.net. 147.95.81.in-addr.arpa. 86400 IN NS ns1.callingcloud.net. 147.95.81.in-addr.arpa. 86400 IN NS ns2.callingcloud.net. 147.95.81.in-addr.arpa. 86400 IN NS ns3.callingcloud.net. ;; Received 176 bytes from 174.121.136.101#53(ns2.callingcloud.net) in 106 ms The Planet (now SoftLayer) supposedly has setup straight class C delegation to ns1/2.callingcloud.net What am I missing here? What dig command can point to the delegation problem? Thanks for any advice, hints or even the bloody answer. --- PD The ns1/3 NSs work as expected: [r...@web0 /]# dig @ns1.callingcloud.net -x 81.95.147.100 +short ns3.callingcloud.net. [r...@web0 /]# dig @ns2.callingcloud.net -x 81.95.147.100 +short ns3.callingcloud.net. [r...@web0 /]# dig @ns3.callingcloud.net -x 81.95.147.100 +short ns3.callingcloud.net. ___ 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 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: NSEC3 ISSUE
Perhaps if dnssecnsec3qatestdomain.com existed we would be able to tell you. As it is there is not enough information here to workout what is broken. In message aanlktik4qlwtydstmwxm-hse8yx88h6tfkpx4cxy8...@mail.gmail.com, rams writes: I have trouble resolving the host name dnssecnsec3qatestdomain.com. which is NSEC3 signed. This is the parent and child zone. If I run dig ( dnssec query) with the +cd option I which is a proper response: [r...@stulcqanusbind1 ~]# dig dnssecnsec3qatestdomain.com. any +dnssec *+cd * ; DiG 9.7.1-P2 dnssecnsec3qatestdomain.com. any +dnssec +cd ; (1 server found) ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 1601 ;; flags: qr rd ra cd; QUERY: 1, ANSWER: 8, AUTHORITY: 3, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;dnssecnsec3qatestdomain.com. IN ANY ;; ANSWER SECTION: dnssecnsec3qatestdomain.com. 86396 IN RRSIG A 7 2 86400 2020083100 20100831205954 61559 dnssecnsec3qatestdomain.com. A4HqcGYSyEoM7Y75MoRaK4zzNiuL45tq+AnfUIrxxEIPkIOI12FmFyhY JOQN216QkTbYkJBlNwe2Ky1SRGjwhQ== dnssecnsec3qatestdomain.com. 86396 IN A 12.12.1.0 dnssecnsec3qatestdomain.com. 86396 IN A 255.12.1.0 dnssecnsec3qatestdomain.com. 86396 IN RRSIG SOA 7 2 86400 2020083100 20100831205954 61559 dnssecnsec3qatestdomain.com. eAV/LHcB3WLA9ULvsz/kcVJ63XeJCX/YAOu9ZFUM+SVDIW/BAUXNfq9O iNBuukgDBlFZFOQyblfgjpcSW3CQMw== dnssecnsec3qatestdomain.com. 86396 IN SOA udns1.ultradns.net. bitbuck...@qa.neustar.com. 2009111903 10800 3600 2592000 86400 dnssecnsec3qatestdomain.com. 86396 IN RRSIG NS 7 2 86400 2020083100 20100831205954 61559 dnssecnsec3qatestdomain.com. r11osNc3HFoVFWjC1iNN9Yv3IKGvApbZwkNLdK5HTlPt+3UDB2Do7RvT 9SSJaZYLj4PEC8Gp6lT1L+0LlsEP9w== dnssecnsec3qatestdomain.com. 86396 IN NS udns2.ultradns.net. dnssecnsec3qatestdomain.com. 86396 IN NS udns1.ultradns.net. ;; AUTHORITY SECTION: dnssecnsec3qatestdomain.com. 86396 IN NS udns2.ultradns.net. dnssecnsec3qatestdomain.com. 86396 IN NS udns1.ultradns.net. dnssecnsec3qatestdomain.com. 86396 IN RRSIG NS 7 2 86400 2020083100 20100831205954 61559 dnssecnsec3qatestdomain.com. r11osNc3HFoVFWjC1iNN9Yv3IKGvApbZwkNLdK5HTlPt+3UDB2Do7RvT 9SSJaZYLj4PEC8Gp6lT1L+0LlsEP9w== But dig (dnssec query)without +cd option returns servfail. [r...@stulcqanusbind1 ~]# dig dnssecnsec3qatestdomain.com. any +dnssec ; DiG 9.7.1-P2 @ dnssecnsec3qatestdomain.com. any +dnssec ; (1 server found) ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: SERVFAIL, id: 7437 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;dnssecnsec3qatestdomain.com. IN ANY In my logs I am getting messages: Jan 7 13:17:55 named[17154]: error (no valid RRSIG) resolving ' dnssecnsec3qatestdomain.com/DNSKEY/IN': 10.31.142.103#53 Jan 7 13:17:55 named[17154]: error (broken trust chain) resolving ' dnssecnsec3qatestdomain.com/ANY/IN': 10.31.142.103#53 When doing query without +cd option. Can you figure out what would be the exact problem? Thanks Regards, Ramesh -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Confused about /24 in-addr.arpa NS delegation debug problem
In message 4d271802.5030...@gmail.com, Gary Wallis writes: Thanks guys for all the feedback. Yes seems like RIPE is involved, and The Planet (TP) refuses to fix delegation or say they can't 'cause of RIPE, but sounds funny to me, and I know that many TP tech support staffers know next to nil about DNS. RIPE and all the RIRs handle this sort of configuration all the time. If The Planet can't get this fixed for you then you really should find another ISP. This is DNS basics and if your ISP can't handle talking to the RIR to get you nameservers registered instead of theirs then what else are they going to get wrong? Mark Have fun with DNS in 2011. Cheers! Gary ___ 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 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: stale cache in alternate views?
The NOTIFY message is only going to one view (external). The simple
solution is to have the internal view transfer the zone from the
external view. I posted how to do this within the last month so
check the archives for examples.
Mark
In message 20110110200940.gn28...@angus.ind.wpi.edu, Chuck Anderson writes:
I'm using bind-9.5.1-P3 (yes, I know it's old). I have a zone in
multiple views. When I update the zone and reload, the match-clients
{ any } view sees new DNS records right away, but another view
doesn't see them for a while.
Given this configuration:
view global {
match-clients { any; };
zone example.net {
type slave;
file /var/named/slaves/example.net.zone;
masters {a.b.c.d;};
};
};
view full {
match-clients { a.b.c.0/24; 127.0.0.1; };
zone example.net {
type slave;
file /var/named/slaves/example.net.zone;
masters {a.b.c.d;};
};
};
If a client in the a.b.c.0/24 subnet queries the server, it doesn't
see recently added DNS records. If a client outside a.b.c.0/24 does
the same query, it sees the new records immediately after the rndc
reload.
Anyone know how to change this behavior?
Thanks.
___
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
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: only the response has aa flag can be cached?
In message 4d2d0689.7010...@chrysler.com, Kevin Darcy writes: The answers will be cached regardless of the setting of the AA flag. I would suspect that most -- or at least a large percentage -- of DNS queries made by endpoint clients are to upstream resolvers which don't happen to be authoritative for the zone(s) in question, so AA=0 is very common in practice and lookup caching wouldn't work very well if it were limited to only AA=1 responses. Authoritative servers should be setting aa in their responses if it is a answer and not a referral (RFC 1034). Referrals don't have normally have aa set, the exception is for out of zone CNAME/DNAME responses where aa should be set for the CNAME/DNAME and a referral is returned as well. There are also some older servers that are broken, BIND 4/8 failed to set aa for CNAMES (fixed in later versions) and promoted glue to answer without setting aa when offering recursive service to the client. Then there are a few authoritative servers that don't set aa even on responses to A queries. These triggered the release of 9.7.2-P1 when we were rejecting these after tightening the response processing to treat glue to answer responses as referrals to address the issue of named return glue records from the parent zones rather than the actual answers in the child zones. After that we shouldn't have needed to accept non aa answers. Note that if a full resolver gets better data in a DNS response than what it has already cached, it may overwrite the existing cache data with the new data. The determination of what is better is spelled out in the data ranking rules in RFC 2181 and isn't directly related to the setting of the AA flag. Among other things, this means that when following a delegation chain, the NS records directly from the authoritative nameservers for a zone, if available, will overwrite the delegating NS records encountered earlier in the resolution process. - Kevin P.S. You did notice that you're performing recursive queries against nameservers which don't offer recursion, right? That might be a possible source of confusion. On 1/4/2011 10:28 PM, p...@mail.nsbeta.info wrote: Hello, I'm not sure about, is it true that only the response which has included the aa in flags can be cached by client DNS Cache? For example, for my domain, there are two queries below, the result for the first query won't be cached, but the second will be cached, am I right? $ dig mail.nsbeta.info ns @ns34.domaincontrol.com ; DiG 9.4.2-P2 mail.nsbeta.info ns @ns34.domaincontrol.com ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 12892 ;; flags: qr rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;mail.nsbeta.info. IN NS ;; ANSWER SECTION: mail.nsbeta.info. 1800IN NS dwdns2.nsbeta.info. mail.nsbeta.info. 1800IN NS dwdns1.nsbeta.info. ;; ADDITIONAL SECTION: dwdns2.nsbeta.info. 3600IN A 219.129.239.5 dwdns1.nsbeta.info. 3600IN A 120.132.133.48 -- $ dig mail.nsbeta.info ns @dwdns2.nsbeta.info ; DiG 9.4.2-P2 mail.nsbeta.info ns @dwdns2.nsbeta.info ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 28561 ;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;mail.nsbeta.info. IN NS ;; ANSWER SECTION: mail.nsbeta.info. 3600IN NS dwdns1.nsbeta.info. mail.nsbeta.info. 3600IN NS dwdns2.nsbeta.info. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ 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 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: query cache denied
In message 20110120021335.5fe392c...@mail.nsbeta.info, p...@mail.nsbeta.info w rites: I saw lots of this info in bind's log: Jan 20 05:25:43 ns2 named[6538]: client 69.10.140.146#33135: query (cache) 's2.xxrz.game.yy.com.cdn20.com/A/IN' denied Jan 20 05:26:47 ns2 named[6538]: client 200.31.4.71#41137: query (cache) 's3.xxrz.game.yy.com.cdn20.com/A/IN' denied I'm using bind-9.6, it's the authoritative name server only. How does the client make a query to request to bind's cache? It asks for a name in a zone that you don't server or are not a parent for. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Telling rndc Which IP Address to Use
Or one can not worry about the IP address being used. The addresses
are still there for backwards compatibilty with BIND 8 where only
the IP address is used. TSIG is really so much stronger than any
IP based authentication. It's like putting a screen door on a bank
vault.
In message 4d38633e.3040...@anl.gov, Barry Finkel writes:
On 01/19/11 15:21, Jay Ford wrote:
On Wed, 19 Jan 2011, Barry Finkel wrote:
I have a master DNS server that has two IP addresses - one used for
DNS and one used for non-DNS. On that master I run rndc to load
zones on slave servers. On the slave servers I have
controls{
inet a.b.c.d port 953
allow {127.0.0.1; e.f.g.h; } keys { rndc-key';};
}
Where e.f.g.h is the DNS address for the master server. Is there a
way on the master to run rndc and tell rndc which IP address to use?
Or do I have to put the non-DNS address of the master in the controls
directive on the slaves. I am running 9.7.2-P3. Thanks.
Does the -b option not suffice?
Jay Ford, Network Engineering Group, Information Technology Services
University of Iowa, Iowa City, IA 52242
email: jay-f...@uiowa.edu, phone: 319-335-, fax: 319-335-2951
I forgot about the -b option.
--
--
Barry S. Finkel
Computing and Information Systems Division
Argonne National Laboratory Phone:+1 (630) 252-7277
9700 South Cass Avenue Facsimile:+1 (630) 252-4601
Building 240, Room 5.B.8 Internet: bsfin...@anl.gov
Argonne, IL 60439-4828 IBMMAIL: I1004994
___
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
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: when one view doesn't have the zone
In message 20110121030937.da19e2c...@mail.nsbeta.info, p...@mail.nsbeta.info w
rites:
Mark Andrews writes:
In message 20110121024745.bcd2e2c...@mail.nsbeta.info, p...@mail.nsbeta.in
fo w
rites:
Hello,
My named.conf looks as:
--
view view_a {
match-clients {
IP_ADDR_A;
};
zone test.com {
type master;
file test.com.a.db;
};
};
view view_b {
match-clients {
IP_ADDR_B;
};
# doesn't have test.com zone here
};
view view_c {
match-clients {
IP_ADDR_C;
};
zone test.com {
type master;
file test.com.c.db;
};
};
--
As you see, test.com doesn't have a zone in view_b.
But view_b should be there because other zones may need it.
So under this case, when clients from ISP_ADDR_B query for test.com, they
will get nothing.
How can I resolve this problem? Thanks in advance.
Sometimes you have to workout what you want the answer to be before
people can tell you how to achieve it. This is one of those times.
What do you want the clients that match view_b to see?
Thanks for pointing me.
In fact I want to the clients that match view_b to fall into the default
view, say it's view_c.
You need view_b to have a copy of view_c's zone. See the archives for
how to do this.
Regards.
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: service if s/up/down/g ipv6
In message 1295741593.4363.79.camel@localhost.localdomain, fakessh @ writes : hello administrators bind. How is it necessary to have a secondary dns server ipv6 in to establish a connection ipv6. I like ipv6 me and one of someone else yet I can not properly establish connections ipv6 I do not even know if I r13151.ovh.net answer properly in ipv6 sincerely=20 --=20 gpg --keyserver pgp.mit.edu --recv-key 092164A7 http://pgp.mit.edu:11371/pks/lookup?op=3Dgetsearch=3D0x092164A7 You need to add a record for r13151.ovh.net if you want it to be addressed by name over IPv6. Mark % dig -6 ns . @r13151.ovh.net dig: couldn't get address for 'r13151.ovh.net': not found % dig -4 ns . @r13151.ovh.net ; DiG 9.6.0-APPLE-P2 -4 ns . @r13151.ovh.net ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: REFUSED, id: 29163 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;. IN NS ;; Query time: 342 msec ;; SERVER: 87.98.186.232#53(87.98.186.232) ;; WHEN: Sun Jan 23 12:58:48 2011 ;; MSG SIZE rcvd: 17 % -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: service if s/up/down/g ipv6
In message 1295764581.4363.93.camel@localhost.localdomain, fakessh @ writes : hello I tried to make a simple box ipv6 r13151.ovh.net did not I know about registration . my domain names such fakessh.eu owns a recording well.=20 You just add records like you would A records e.g. host 3600 IN A 1.2.3.4 host 3600 IN 2002:1234:abde:1b78:2002:1234:abde:1b78 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: service if s/up/down/g ipv6
In message 201101241636.57884.fake...@fakessh.eu, fakessh writes: Le lundi 24 janvier 2011 00:04, vous avez =C3=A9crit=C2 : At this stage I think you will need to post the zone so we can see what you have done. Also the named.conf zone clause for ovh.net. Marc thank you for your attention as you bear me, thank you very humbly i paste my named.conf and the zone whitout signatures , work for me http://pastebin.com/7Be9FavZ This is the zone for fakessh.eu. I requested the zone for ovh.net because you asked if r13151.ovh.net was reachable over IPv6. To do that we needed r13151.ovh.net's IPv6 address just like we need its IPv4 address to test if we can reach it over IPv4. If you are just worried that the address are being published in the fakessh.eu then they are. % dig www.fakessh.eu +short 2001:41d0:2:3dd6:1234:5678:9abc:def0 % http://pastebin.com/XFuc45tM nb : if I create a new thread in the list Excuse me Mark has bothered to=20 answer me personally in my INBOX from the list, so I think my answer will n= ot=20 be synchronized with the list =2D-=20 http://pgp.mit.edu:11371/pks/lookup?op=3Dgetsearch=3D0x092164A7 gpg --keyserver pgp.mit.edu --recv-key 092164A7 --nextPart4788602.X930IZQvoN Content-Type: application/pgp-signature -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQBNPZyZtXI/OwkhZKcRAlMRAJ95rVtknVtShDdm9IqlzRGD/MjhiQCggZkB D5NsZ1Pevuw6mBHkX2SmMcc= =TBXv -END PGP SIGNATURE- --nextPart4788602.X930IZQvoN-- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: service if s/up/down/g ipv6
In message 1295898474.4615.5.camel@localhost.localdomain, fakessh @ writes: thank you for this very constructive reflection. I just changed the zone r13151.ovh.net it contained only fields ptr ns and I just added a field and . I increment the serial then all and apply rndc reload flush reconfig sign all zone dig answer now seems r13151 ~]# dig +short r13151.ovh.net 2001:41d0:2:3dd6:1234:5678:9abc:def0 That address in not reachable. It's also not published to the world. ; DiG 9.6.0-APPLE-P2 r13151.ovh.net ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 53882 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;r13151.ovh.net.IN ;; AUTHORITY SECTION: ovh.net.223 IN SOA dns10.ovh.net. tech.ovh.net. 2011012410 86400 3600 360 600 ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Tue Jan 25 08:58:35 2011 ;; MSG SIZE rcvd: 79 ; DiG 9.6.0-APPLE-P2 fakessh.eu +norec @2001:41d0:2:3dd6:1234:5678:9abc:def0 ;; global options: +cmd ;; connection timed out; no servers could be reached % traceroute6 -I 2001:41d0:2:3dd6:1234:5678:9abc:def0 traceroute6 to 2001:41d0:2:3dd6:1234:5678:9abc:def0 (2001:41d0:2:3dd6:1234:5678:9abc:def0) from 2001:470:1f00:820:ea06:88ff:fef3:4f9c, 64 hops max, 16 byte packets 1 bsdi 4.294 ms 4.414 ms 4.348 ms 2 tunnel820.tserv1.fmt.ipv6.he.net 184.739 ms 184.951 ms 184.252 ms 3 v702.core1.fmt1.he.net 190.944 ms 185.803 ms 205.290 ms 4 gige-g4-8.core1.fmt2.he.net 193.800 ms 185.499 ms 188.133 ms 5 10gigabitethernet6-4.core1.lax1.he.net 195.345 ms 192.132 ms 195.376 ms 6 10gigabitethernet4-3.core1.nyc4.he.net 253.409 ms 258.000 ms 253.955 ms 7 10gigabitethernet1-2.core1.lon1.he.net 321.876 ms 328.994 ms 324.858 ms 8 10gigabitethernet1-1.core1.ams1.he.net 339.823 ms 329.418 ms 344.208 ms 9 10gigabitethernet1-1.core1.fra1.he.net 336.818 ms 344.800 ms 336.734 ms 10 decix.routers.ovh.net 338.047 ms 337.641 ms 348.496 ms 11 vss-2-6k.fr.eu 345.997 ms 363.553 ms 348.756 ms 12 vss-2-6k.fr.eu 3342.128 ms !A 3349.602 ms !A 3348.035 ms !A % Le lundi 24 janvier 2011 =C3=A0 17:57 +0100, Eivind Olsen a =C3=A9crit : http://pastebin.com/7Be9FavZ =20 That zonefile seems to be for fakessh.eu, and not for ovh.net. Your initial problem was regarding IPv6 towards r13151.ovh.net ? If so, that's the zonefile we'll need to look at. =20 Regards Eivind Olsen =20 =20 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users --=20 gpg --keyserver pgp.mit.edu --recv-key 092164A7 http://pgp.mit.edu:11371/pks/lookup?op=3Dgetsearch=3D0x092164A7 --=-J0981zr9QuD4DtkUiCpt Content-Type: application/pgp-signature; name=signature.asc Content-Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?= -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQBNPddqtXI/OwkhZKcRAvDFAKCGFNDi6UQYWEY3gfHCNBUM92g9lACeJFtK 4ryX8hpFeWol1ikygzAGHsk= =FDkY -END PGP SIGNATURE- --=-J0981zr9QuD4DtkUiCpt-- --===0053086760583786854== Content-Type: text/plain; charset=us-ascii MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users --===0053086760583786854==-- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Bind with publicly routable DDNS mappings for IPv6 but not IPv4
(hostname: pinky) connects to the network, and now everyone on the internal network can ping either pinky or a href=http:/ /pinky.example.com/ target=_blankpinky.example.com/a. If they are IPv4 only, they will get pinky's IPv4 leased address, and if they are dual-stack or IPv6 they will get pinky's IPv6 address since a href=http ://pinky.riebart.ca/pinky.riebart.ca/a will have both A and records. I also want anyone on the internet at large to be able to ping a href=http://pinky.exam ple.com/ target=_blankpinky.example.com/a and, if they are IPv6 enabled, will get replies since pinky's IPv6 address is publicly routable. Attempts to get an A record for a href=http:/ /pinky.example.com/pinky.example.com/a should fail.br br Problem is, how do I do this without polluting the internet with my private IPv4 DDNS mappings and without requiring an extra subdomain? The inside clients need to see both the IPv6 and IPv4 mappings, but the external queries should never see the IPv4 mappings. I can't just copy-past the zone files since they are both being dynamicly updated through DDNS. Additionally, since the DHCP client support for DHCP option 119 (DNS domain search list) is pretty abysmal I would really like to not have t o put ipv4 mappings onto lt;HOSTNAMEgt;.a href=http://ipv4.example.com/; ipv4.example.com/a.br brAny suggestions?brbrThanks,brMike ___brbind-users mailing listbr a href=mailto:bind-users@lists.isc.org;bind-users@lists.isc.org/abrht tps://lists.isc.org/mailman/listinfo/bind-users/blockquote/divbr/body /html --Apple-Mail-64--231457544-- --===0962283465469852765== Content-Type: text/plain; charset=us-ascii MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users --===0962283465469852765==-- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
BIND 9.6.3rc1 is now available
Introduction BIND 9.6.3rc1 is the first release candidate for BIND 9.6.3. This document summarizes changes from BIND 9.6.2-P2 to BIND 9.6.3. Please see the CHANGES file in the source code release for a complete list of all changes. Download The latest development version of BIND 9 software can always be found on our web site at http://www.isc.org/downloads/development. There you will find additional information about each release, source code, and some pre-compiled versions for certain operating systems. Support Product support information is available on http://www.isc.org/services/support for paid support options. Free support is provided by our user community via a mailing list. Information on all public email lists is available at https://lists.isc.org/mailman/listinfo. New Features 9.6.3 None. Feature Changes 9.6.3 None. Security Fixes 9.6.2-P3 * Adding a NO DATA signed negative response to cache failed to clear any matching RRSIG records already in cache. A subsequent lookup of the cached NO DATA entry could crash named (INSIST) when the unexpected RRSIG was also returned with the NO DATA cache entry. [RT #22288] [CVE-2010-3613] [VU#706148] * BIND, acting as a DNSSEC validator, was determining if the NS RRset is insecure based on a value that could mean either that the RRset is actually insecure or that there wasn't a matching key for the RRSIG in the DNSKEY RRset when resuming from validating the DNSKEY RRset. This can happen when in the middle of a DNSKEY algorithm rollover, when two different algorithms were used to sign a zone but only the new set of keys are in the zone DNSKEY RRset. [RT #22309] [CVE-2010-3614] [VU#837744] Bug Fixes 9.6.3 * BIND now builds with threads disabled in versions of NetBSD earlier than 5.0 and with pthreads enabled by default in NetBSD versions 5.0 and higher. Also removes support for unproven-pthreads, mit-pthreads and ptl2. [RT #19203] * HPUX now correctly defaults to using /dev/poll, which should increase performance. [RT #21919] * If named is running as a threaded application, after an rndc stop command has been issued, other inbound TCP requests can cause named to hang and never complete shutdown. [RT #22108] * When performing a GSS-TSIG signed dynamic zone update, memory could be leaked. This causes an unclean shutdown and may affect long-running servers. [RT #22573] * A bug in NetBSD and FreeBSD kernels with SO_ACCEPTFILTER enabled allows for a TCP DoS attack. Until there is a kernel fix, ISC is disabling SO_ACCEPTFILTER support in BIND. [RT #22589] * Corrected a defect where a combination of dynamic updates and zone transfers incorrectly locked the in-memory zone database, causing named to freeze. [RT #22614] * Don't run MX checks (check-mx) when the MX record points to .. [RT #22645] * DST key reference counts can now be incremented via dst_key_attach. [RT #22672] * isc_mutex_init_errcheck() in phtreads/mutex.c failed to destroy attr. [RT #22766] * The Kerberos realm was being truncated when being pulled from the the host prinicipal, make krb5-self updates fail. [RT #22770] * named failed to preserve the case of domain names in RDATA which is not compressible when writing master files. [RT #22863] 9.6.2-P3 * Worked around a race condition in the cache database memory handling. Without this fix a DNS cache DB or ADB could incorrectly stay in an over memory state, effectively refusing further caching, which subsequently made a BIND 9 caching server unworkable. [RT #21818] * Microsoft changed the behavior of sockets between NT/XP based stacks vs Vista/windows7 stacks. Server 2003/2008 have the older behavior, 2008r2 has the new behavior. With the change, different error results are possible, so ISC adapted BIND to handle the new error results. This resolves an issue where sockets would shut down on Windows servers causing named to stop responding to queries. [RT #21906] * Windows has non-POSIX compliant behavior in its rename() and unlink() calls. This caused journal compaction to fail on Windows BIND servers with the log error: dns_journal_compact failed: failure. [RT #22434] Thank You Thank you to everyone who assisted us in making this release possible. If you would like to contribute to ISC to assist us in continuing to make quality open source software, please visit our donations page at http://www.isc.org/supportisc. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing
BIND 9.7.3rc1 is now available.
cause named to hang and never complete shutdown. [RT #22108] * An NSEC3PARAM record placed inside a zone which is not properly signed with NSEC3 could cause named to crash, if changed via dynamic update. [RT #22363] * rndc -h now includes loadkeys option. [RT #22493] * When performing a GSS-TSIG signed dynamic zone update, memory could be leaked. This causes an unclean shutdown and may affect long-running servers. [RT #22573] * A bug in NetBSD and FreeBSD kernels with SO_ACCEPTFILTER enabled allows for a TCP DoS attack. Until there is a kernel fix, ISC is disabling SO_ACCEPTFILTER support in BIND. [RT #22589] * Corrected a defect where a combination of dynamic updates and zone transfers incorrectly locked the in-memory zone database, causing named to freeze. [RT #22614] * Don't run MX checks (check-mx) when the MX record points to .. [RT #22645] * DST key reference counts can now be incremented via dst_key_attach. [RT #22672] * dnssec-settime -S no longer tests prepublication interval validity when the interval is set to 0. [RT #22761] * isc_mutex_init_errcheck() in phtreads/mutex.c failed to destroy attr. [RT #22766] * The Kerberos realm was being truncated when being pulled from the the host prinicipal, make krb5-self updates fail. [RT #22770] * named failed to preserve the case of domain names in RDATA which is not compressible when writing master files. [RT #22863] 9.7.2-P3 * Microsoft changed the behavior of sockets between NT/XP based stacks vs Vista/windows7 stacks. Server 2003/2008 have the older behavior, 2008r2 has the new behavior. With the change, different error results are possible, so ISC adapted BIND to handle the new error results. This resolves an issue where sockets would shut down on Windows servers causing named to stop responding to queries. [RT #21906] * Windows has non-POSIX compliant behavior in its rename() and unlink() calls. This caused journal compaction to fail on Windows BIND servers with the log error: dns_journal_compact failed: failure. [RT #22434] 9.7.2-P1 * A bug, introduced in BIND 9.7.2, caused named to fail to start if a master zone file was unreadable or missing. This has been corrected in 9.7.2-P1. * BIND previously accepted answers from authoritative servers that did not provide a proper response, such as not setting AA bit. BIND was changed to be more strict in what it accepted but this caused operational issues. This new strictness has been backed out in 9.7.2-P1. 9.7.2 * Removed a warning message when running BIND 9 under Windows for when a TCP connection was aborted. This is a common occurrence and the warning was extraneous. * Worked around a race condition in the cache database memory handling. Without this fix a DNS cache DB or ADB could incorrectly stay in an over memory state, effectively refusing further caching, which subsequently made a BIND 9 caching server unworkable. * Partially disabled change 2864 because it would cause infinite attempts of RRSIG queries. * BIND did not properly handle non-cacheable negative responses from insecure zones. This caused several non-protocol-compliant zones to become unresolvable. BIND is now more accepting of responses it receives from less strict servers. Known issues in this release * make test will fail on OSX and possibly other operating systems. The failure occurs in a new test to check for allow-query ACLs. The failure is caused because the source address is not specified on the dig commands issued in the test. If running make test is part of your usual acceptance process, please edit the file bin/tests/system/allow_query/test.sh and add -b 10.53.0.2 to the DIGOPTS line. Thank You Thank you to everyone who assisted us in making this release possible. If you would like to contribute to ISC to assist us in continuing to make quality open source software, please visit our donations page at http://www.isc.org/supportisc. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC auto-dnssec issue bind-9.7.2-P3
In message c964b3cd.13a61%kalman.fe...@melbourneit.com.au, Kalman Feher write s: On 25/01/11 4:10 PM, Alan Clegg acl...@isc.org wrote: On 1/25/2011 9:51 AM, Kalman Feher wrote: If the nsec3param has been removed, the automated signing will be weird if you are using nsec3 keys. I havent tested this scenario, since it isnt really a working scenario. There is no such thing as an nsec3 key. Sorry, I was a little sloppy with my vernacular. I meant the algorithm used to create the keys in question. ie using -3 in dnssec-keygen. And *all* keys that support NSEC3 are also NSEC capable. There isn't such a thing as a NSEC3 key. There are NSEC3 capable keys and keys that are not NSEC3 capable. All keys are NSEC capable. As for the NSEC3PARAM going away it is only supposed to exist in a *signed* zone and you are attempting to add it to a unsigned zone. The key timing are there for managing keys in a already signed zone. You are attempting to use them to start signing the zone which requires as whole different set of steps to be done. To get named to convert a unsigned zone to a signed zone with NSEC3 use nsupdate to add the DNSKEYs and NSEC3PARAM record in the same UPDATE request. If you auto-sign a zone that does not contain an NSEC3PARAM record, the zone will be signed using NSEC. That was the observed behaviour of the OP, which wasn't their preference. Hence the need to add and retain said nsec3param in this instance. [note that I'm leaving the rest of that mail to be responded to by someone with more intimate knowledge of the auto-signing mechanism] AlanC ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- Kal Feher ___ 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 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: root hints
In message 20110126003702.c16...@gwyn.tux.org, Joseph S D Yao writes: On Wed, Jan 26, 2011 at 11:20:18AM +0800, p...@mail.nsbeta.info wrote: Hello, From what version of bind we won't include the root hints file in named.conf? Since the bind server has been including it inherently. I could be wrong, but I think that all V9 and even all V8 had this feature. I include them anyway - because sometimes I need to change what's hidden in the program. With current V9 you can 'cp /dev/null $directory/named.conf' and have 'named' work fine. But I have only done this once, just for the experience. You don't even need the copy. named -c /dev/null will do the job if you just want a recursive server for the local network. -- /*\ ** ** Joe Yaoj...@tux.org - Joseph S. D. Yao ** \*/ ___ 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 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: bind Bind or BIND?
In message 20110127020201.861a52d...@mail.nsbeta.info, p...@mail.nsbeta.info writes: When talk to others, I never describe it clearly for naming bind. is it bind or Bind or BIND? is bind an abbreviation word? BIND stands for Berkley Internet Name Domain. Thanks. ___ 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 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: IXFR and AXFR
In message e39f60e8c9db5f989a369841cd92a6e1.squir...@webmail.aminor.no, Eivind Ols en writes: At what time the slave executes AXFR and at what time it executes IXFR from the master? Someone please correct me if I give misleading information. I don't believe I am, but I've been wrong before :D There's a good section about this in the ARM, such as BIND 9.7 ARM section 4.3 - Incremental Zone Transfers (IXFR). Basically, a BIND 9 slave will normally ask for IXFR unless told not to (request-ixfr). A BIND 9 master can't always provide IXFR though - if it can't it will provide AXFR instead. To be able to provide IXFR it needs to have some idea of the changes being made, so it can give a meaningful reply when asked to provide all changes since serial number X, so you'll normally see IXFR being possible for dynamically updated zones (and a couple of other cases, check the ARM). Regards Eivind Olsen named will do a axfr initially, anytime it believes it has lost sync with the master (the ixfr did not apply without error), when rndc retransfer is called, when ixfr is rejected by the master. The master will return a AXFR style IXFR whenever it doesn't have the requested axfr stream. ___ 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 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: IXFR and AXFR
In message 20110127124124.5b8ed2d...@mail.nsbeta.info, p...@mail.nsbeta.info writes: Mark Andrews writes: The master will return a AXFR style IXFR whenever it doesn't have the requested a xfr stream. Do you mean whenever it doesn't have the requested IXFR stream? When you make a IXFR request you say please send me the changes starting at this serial. Sometimes the master will have already discarded some or all of the changes. IXFR allows for optional compression of deltas and if one of the masters in the axfr graph does that and you have multiple masters listed you make end up ask a master that about a serial that was compressed away. Thanks. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Bind 9.7 - sanity check or a bug
In message 4d42a8df.10...@imperial.ac.uk, Phil Mayers writes: On 28/01/11 10:50, Din Jo wrote: case 1: # nsupdate server 127.0.0.1 update delete server2.test.com http://server2.test.com A update add server2.test.com http://server2.test.com A 10.0.0.2 send quit case 2: # nsupdate server 127.0.0.1 update delete server2.test.com http://server2.test.com A send update add server2.test.com http://server2.test.com A 10.0.0.2 send update failed: REFUSED quit In case one, you are deleting the old A record and adding the new one in the same update transaction. In case two, you are sending the delete as one transaction and the add as a 2nd transaction. I'm surprised the 2nd case fails at the 2nd transaction, not the first. Known bug. The version information was not passed down to the checking routines. ___ 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 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: root hints
In message barmar-a10cc5.23122928012...@news.eternal-september.org, Barry Mar golin writes: In article mailman.1562.1296270623.555.bind-us...@lists.isc.org, Joseph S D Yao j...@tux.org wrote: [This does leave a security hole - if a root name server's IP changes, and a Bad Guy gets the old one; or on another internet, if the Bad Guy gets all the IP addresses in the default file. It's not just lust for control that has me using a visible root hints file.] I'm sure the folks who run these networks are quite aware of this danger. If a root server changes, I'll bet it will be several years before the old address goes to some other organization. How would a Bad Guy get these blocks, anyway? Since when do organizations return IP blocks. And if you check the registrations, several of them are assigned specifically to reserve the blocks for root servers. Presumably the intent is that even if the organizations operating them change, the IPs shouldn't -- they simply route the IPs to someone else. inetnum:202.12.27.0 - 202.12.27.255 netname:NSPIXP-2 descr: root DNS server NetRange: 199.7.83.0 - 199.7.83.255 CIDR: 199.7.83.0/24 OriginAS: AS20144 NetName:L-ROOT -- Barry Margolin, bar...@alum.mit.edu Arlington, MA *** PLEASE don't copy me on replies, I'll read them in the group *** ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users And one can always turn on DNSSEC and then it doesn't matter which server gives you the information. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: cache server with authoritative answer
In message aanlktinnokvhtux8f9-dfgcl2lkzjfe+wmb_xxk0r...@mail.gmail.com, Chris Buxton writes: No, BIND 8 was broken this was also. This was fixed in BIND 9. As for non-BIND name servers, anything goes. Chris Buxton BlueCat Networks It depended on the BIND 8 version. Running everything through the cache cleaned up the answers the stub resolvers saw. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DS record in child zone
In message 4d4693cb.60...@dialtelecom.cz, rysl...@dialtelecom.cz writes: Hello, we have a DNS resolver running the latest 9.7 bind version, and there is a problem with several zones from these authoritative servers (frantovo.cz is just and example, the problem prevails in all signed zones from these authoritative servers): frantovo.cz.3111IN NS ns.forpsi.net. frantovo.cz.3111IN NS ns.forpsi.cz. frantovo.cz.3111IN NS ns.forpsi.it. Our resolver logis this: 31-Jan-2011 11:45:30.837 dnssec: debug 3: validating @0xd69c000: frantovo.cz NS: starting 31-Jan-2011 11:45:30.837 dnssec: debug 3: validating @0xd69c000: frantovo.cz NS: attempting insecurity proof 31-Jan-2011 11:45:30.837 dnssec: debug 3: validating @0xd69c000: frantovo.cz NS: checking existence of DS at 'cz' 31-Jan-2011 11:45:30.837 dnssec: debug 3: validating @0xd69c000: frantovo.cz NS: checking existence of DS at 'frantovo.cz' 31-Jan-2011 11:45:30.837 dnssec: debug 3: validating @0xd69c000: frantovo.cz NS: insecurity proof failed 31-Jan-2011 11:45:30.837 dnssec: info: validating @0xd69c000: frantovo.cz NS: got insecure response; parent indicates it should be secure The problem arises from the fact that all these servers fail to respond to queries on DS record for their zones: # dig @ns.forpsi.cz frantovo.cz ds ; DiG 9.7.2-P2 @ns.forpsi.cz frantovo.cz ds ; (1 server found) ;; global options: +cmd ;; connection timed out; no servers could be reached Which is strange, because according to RFCs, the DS record for a given zone is required only in the parent zone, not the child zone itself. Does BIND query for the existence of a DS record in the child zone, and if so, why? Or is the cause of the problem different? What makes you think named asked those servers? DS at 'frantovo.cz' will be asked to the parent (cz) zone. Any advice would be welcome, thanks in advance. Best Regards Daniel Ryslink ___ 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 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Clarification on wildcard scenario
In message AANLkTi=mms6aghguqyt1pmllyqfz2zp0su6yqwqmx...@mail.gmail.com, rams w rites: Hi, I have zone as follows in bind. $ORIGIN joshfeb1.com. @ IN SOA rboddeti.yahoo.com. rboddeti.gmail.com. ( 2011013101 ; serial 10800 ; refresh 3600 ; retry 2592000 ; expire 86400 ; minimum ) joshfeb1.com. NS udns1.ultradns.net. joshfeb1.com. NS udns2.ultradns.net. **.joshfeb1.com A 1.1.1.1 *.www.joshfeb1.com A 2.2.2.2* When I queried domain www.joshfeb1.com. A against Bind, I am getting NXDOMAIN.When can i get records in response. Could you please clarify me. The following response return. *[root@zones]# dig abc.www.joshfeb1.com. A* ; DiG 9.6.1-P3 abc.www.joshfeb1.com. A ; (1 server found) ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 24113 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;abc.www.joshfeb1.com. IN A ;; AUTHORITY SECTION: joshfeb1.com. 86400 IN SOA udns1.ultradns.net. rboddeti.infinite.com. 2011013101 10800 3600 2592000 86400 ;; Query time: 2 msec ;; SERVER: 10.31.145.194#53(10.31.145.194) ;; WHEN: Tue Feb 1 03:36:56 2011 ;; MSG SIZE rcvd: 110 *[root@ zones]# dig abc.joshfeb1.com. A* ; DiG 9.6.1-P3 abc.joshfeb1.com. A ; (1 server found) ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 26354 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;abc.joshfeb1.com. IN A ;; AUTHORITY SECTION: joshfeb1.com. 86400 IN SOA udns1.ultradns.net. rboddeti.infinite.com. 2011013101 10800 3600 2592000 86400 ;; Query time: 2 msec ;; SERVER: 10.31.145.194#53(10.31.145.194) ;; WHEN: Tue Feb 1 03:37:05 2011 ;; MSG SIZE rcvd: 106 *[root@ zones]# dig www.joshfeb1.com. A* ; DiG 9.6.1-P3 www.joshfeb1.com. A ; (1 server found) ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 19448 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;www.joshfeb1.com. IN A ;; AUTHORITY SECTION: joshfeb1.com. 86400 IN SOA udns1.ultradns.net. rboddeti.infinite.com. 2011013101 10800 3600 2592000 86400 ;; Query time: 2 msec ;; SERVER: 10.31.145.194#53(10.31.145.194) ;; WHEN: Tue Feb 1 03:37:15 2011 ;; MSG SIZE rcvd: 106 [root@stulcqacustbind2 zones]# What bind is returning is correct? Yes. You have a mixture of relative (no period at end) and absolute names (period at end) in the zone file above. What you added to the zone was www.joshfeb1.com.joshfeb1.com. not www.joshfeb1.com.. You needed a period at the end of com or to just use www. Mark Thanks Regards, Ramesh -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Clarification on wildcard scenario
In message AANLkTin+PmzXYUVbCVX3D=Mh1S75ddpMwhjuE9r5zk2=@mail.gmail.com, rams w rites: Hi, I have zone as follows in bind. $ORIGIN joshfeb1.com. @ IN SOA rboddeti.yahoo.com. rboddeti.gmail.com. ( 2011013101 ; serial 10800 ; refresh 3600 ; retry 2592000 ; expire 86400 ; minimum ) joshfeb1.com. NS udns1.ultradns.net. joshfeb1.com. NS udns2.ultradns.net. **.joshfeb1.com. A 1.1.1.1 *.www.joshfeb1.com. http://www.joshfeb1.com/ A 2.2.2.2* It gets very hard when your email client adds to the plain text version. We really don't need extra * and http://www.joshfeb1.com/ added. You want the records to be like this: *.joshfeb1.com. A 1.1.1.1 www.joshfeb1.com. A 2.2.2.2 You has a wildcard before the www creating a empty node in the tree. When I queried domain www.joshfeb1.com. A against Bind, I am getting NOERROR and NOANSWER.When can i get answer. Could you please clarify me. I able to get answer with abc.joshfeb1.com and abc.www.joshfeb1.com. Why bind is not returning answer for www.joshfeb1.com, it should map to **. joshfeb1.com. right? Thanks Regards, Ramesh * Thanks Regards, Ramesh -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: [OT] does deliveragent must have a PTR RR
In message 4d4784c4.2020...@lcrcomputer.net, Lyle Giese writes: p...@mail.nsbeta.info wrote: Hi list, I can't setup a ptr RR for my mailserver's IP. Here the main ISPs who are owned by this garbage state take expensive price for setup a reverse record for a public IP. It's about 30 USD each month for each IP. But some MTAs does require the peer deliveragent has a PTR RR,like AOL's email systems. Is there a special RFC for this requirement? Regards. Mail Delivery System writes: This is the mail system at host mail.nsbeta.info. I'm sorry to have to inform you that your message could not be delivered to one or more recipients. It's attached below. For further assistance, please send mail to postmaster. If you do so, please include this problem report. You can delete your own text from the attached returned message. The mail system dono...@beth.k12.pa.us: host mx1.beth.k12.pa.us[209.96.96.11] said: 450 4.7.1 Client host rejected: cannot find your reverse hostname, [121.9.221.212] (in reply to RCPT TO command) I do not believe this to be fully covered in an RFC, but came about as Best Practices as we fight SPAM. The best source for the Best Practices for this is at http://postmaster.aol.com And is also against RFC requirements. Wonder through ALL of the pages that this area at AOL has to offer or you will miss some important points, like that 12 hrs is considered the min TTL for A and PTR records for mail servers. Less than 12 hrs TTL on these records are considered by default indicators of dynamic IP addresses. You can't infer diddly squat from a TTL. There are plenty of reasons to want a low ttl other than it was assigned dynamically. * I'm going to renumber my whole network because I'm switchinhg ISP's so I've reduced my TTL's to 5 minutes to reduce the impact of the renumbering. * I have a warm spare in a different data center and as most client behave badly when one of the addresses is unreachable I only advertise one address. More stupid unrealistic hoops to jump through. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Again Crashed Bind
Upgrade as recommended in CVE-2010-3613. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: bind makes RRSIG disappear?
In message 4d4ef872.6070...@restena.lu, Gilles Massen writes: Chris, thanks for the hint, but: On 6/2/11 19:20 , Chris Thompson wrote: On Feb 6 2011, Gilles Massen wrote: I have a very peculiar behavior: a zone, signed by OpenDNSSEC and pushed to Bind 9.7.2-P3 by scp was working fine. But now, completely out of the blue, Bind decides to claim some authority over the zone: the SOA RRSIG (only that one) is scrapped, and this is logged: [...] Presumably you are defining the zone to BIND as type master. Yes. Does your configuration also have an allow-update setting (other than none) for it, maybe only for the instance that is giving you trouble? In that case BIND will take it that you want it to do resigning as the RRSIGs approach expiry. The only allow-update is in the options section, and none. Get rid of the allow-update and allow the default of no acl to work. BTW, the config has not changed in months, only the zone got only signed. Besides, at least the SOA RRSIG is pretty recent. Other signatures that disappear are still 7 days from expiry. Best, Gilles ___ 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 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: dealing with multi-homed machine
In message 3ad9c812-cba3-4dcd-a27e-26e63d912...@beth.k12.pa.us, donovan jeffr ey j writes: Greetings I have an external dns server that serves a group of systems. One of the syst ems has a secondary interface with private address space. Dns should not be r equesting from here but i am seeing these warnings coming from my external sy stem; security: warning: client 209.96.96.108#49534: view com.basd.DNS.public: RFC 1918 response from Internet for 108.1.135.10.in-addr.arpa how do I keep that internal zone from being seen ? Do I have to firewall dns queries between interfaces on the server ? tia Please go read the FAQ. http://www.isc.org/software/bind/faq -j ___ 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 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: dealing with multi-homed machine
In message c7798a38-e7ae-4112-a6b6-8ca117fee...@beth.k12.pa.us, donovan jeffr
ey j writes:
On Feb 8, 2011, at 5:17 PM, Mark Andrews wrote:
In message 3ad9c812-cba3-4dcd-a27e-26e63d912...@beth.k12.pa.us, donovan j
effr
ey j writes:
Greetings
I have an external dns server that serves a group of systems. One of the s
yst
ems has a secondary interface with private address space. Dns should not b
e r
equesting from here but i am seeing these warnings coming from my external
sy
stem;
security: warning: client 209.96.96.108#49534: view com.basd.DNS.public: R
FC
1918 response from Internet for 108.1.135.10.in-addr.arpa
how do I keep that internal zone from being seen ? Do I have to firewall d
ns
queries between interfaces on the server ?
tia
Please go read the FAQ. http://www.isc.org/software/bind/faq
thanks mark,
It appears my case may be a programming error from the server admin. But this
brings up the case of views.
on my external dns server i should add an empty zone file ? what does that se
nd back to the offending request?
It sends back NXDOMAIN responses except for apex queries. This is all
the public servers do.
zone 10.IN-ADDR.ARPA {
type master;
file empty;
};
is there a way i can redirect him back to the Internal dns server for 1918 re
quests,... ( and i think the answer is ,.. let the internal answer the initia
l request so it never comes up to the outside).
The internal DNS servers, handed out by DHCP, should be configured
to serve the IN-ADDR.ARPA reverse zones for the RFC 1918 addresses
you are using. You can then add PTR records for your internal
machines using RFC 1918 addresses.
Because they wern't configured to do so the queries leaked out to
the Internet and the code to report these leaks kicked in.
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: compile error bind-9.7.2-P3 osx 10.5.8 ppc
In message 74303900-b549-4bd3-a4ed-e7ae8f838...@beth.k12.pa.us, donovan jeffr ey j writes: greetings i was able to update ssl to OpenSSL 1.0.0c 2 Dec 2010 when i try and recompile bind I get an error on make Undefined symbols: _RSA_generate_key_ex, referenced from: _opensslrsa_generate in libdns.a(opensslrsa_link.o) _DSA_generate_parameters_ex, referenced from: _openssldsa_generate in libdns.a(openssldsa_link.o) _DH_generate_parameters_ex, referenced from: _openssldh_generate in libdns.a(openssldh_link.o) ld: symbol(s) not found collect2: ld returned 1 exit status make[2]: *** [named] Error 1 make[1]: *** [subdirs] Error 1 make: *** [subdirs] Error 1 Make sure you build shared libraries when you build openssl. OSX's linker prefers shared libraries over static libraries and as the system's libraries are shared the static ones are skipped. ___ 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 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: [SOLVED] Re: BIND9 SERVFAIL on some .gov addresses
max-udp-size controls what you send. MAX(512, MIN(max-udp-size, client's UDP size)) edns-udp-size controls what you advertise you can receive. MAX(512, MIN(edns-udp-size, server's UDP size)) -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: additional empty zones
In message 20110212220459.ga23...@fantomas.sk, Matus UHLAR - fantomas writes:
2011/2/12 Matus UHLAR - fantomas uh...@fantomas.sk:
Is it possible to add additional zones as empty?
On 12.02.11 11:15, Terry. wrote:
depends on what is empty.
exactly the same what is used by disable-empty-zones option.
I'd like to have opposite option.
zone xxx {
type master;
database _builtin empty nameserver contact;
};
should do it.
--
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.
There's a long-standing bug relating to the x86 architecture that
allows you to install Windows. -- Matthew D. Fuller
___
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
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: additional empty zones
In message 20110213155712.ga1...@fantomas.sk, Matus UHLAR - fantomas writes:
On 13.02.11 09:25, Mark Andrews wrote:
In message 20110212220459.ga23...@fantomas.sk, Matus UHLAR - fantomas writ
es:
2011/2/12 Matus UHLAR - fantomas uh...@fantomas.sk:
Is it possible to add additional zones as empty?
On 12.02.11 11:15, Terry. wrote:
depends on what is empty.
exactly the same what is used by disable-empty-zones option.
I'd like to have opposite option.
zone xxx {
type master;
database _builtin empty nameserver contact;
};
should do it.
Nice, but is that documented enough so the behaviour won't change or get
removed in later releases?
It's unlikely to change.
... and it would be nice without the nameserver and contact parts, since
they are usually defined by empty-server and empty-contact options
For the zones named creates. Named isn't creating these zones. You are.
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Spurious TYPE65534 at the end of a NSEC3, why?
In message 4d5806ef.7000...@imperial.ac.uk, Phil Mayers writes: On 02/13/2011 11:35 AM, Stephane Bortzmeyer wrote: On Sun, Feb 13, 2011 at 10:51:30AM +, Phil Mayersp.may...@imperial.ac.uk wrote a message of 31 lines which said: This is documented in the Bind ARM OK, thanks, I missed this section. i.e. the *presence* of the record is normal. I'm not convinced (and the ARM is far from clear about it). Well, you're correct that they are absent most of the time. OTOH I have a zone (NSEC not NSEC3) which is managed by dynamic updates currently has a TYPE65534 at the apex, and the NSEC record names the TYPE65534 and it's RRSIG is valid - try: dig +dnssec bar.ic.ac.uk (assuming the TYPE65534 doesn't vanish... in the meantime) IOW, it sounds like a bug in the code for NSEC3, because I think it works for NSEC. I could reproduce it in 9.7.1-P1 by just adding a DNSKEY record at the apex but not in 9.7.2. There were a number of NSEC3 fixes between 9.7.1 and 9.7.2. Upgrade. ___ 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 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
BIND 9.7.3 is now available.
will fail on OSX and possibly other operating systems. The failure occurs in a new test to check for allow-query ACLs. The failure is caused because the source address is not specified on the dig commands issued in the test. If running make test is part of your usual acceptance process, please edit the file bin/tests/system/allow_query/test.sh and add -b 10.53.0.2 to the DIGOPTS line. Thank You Thank you to everyone who assisted us in making this release possible. If you would like to contribute to ISC to assist us in continuing to make quality open source software, please visit our donations page at http://www.isc.org/supportisc. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
BIND 9.8.0rc1 is now available.
timeout in seconds) to set a different value than the default (30
seconds). A value of 0 means 'use the compiled in default';
anything longer than 30 will be silently set to 30. [RT #22852]
* For Mac OS X, you can now have the test interfaces used during
make test stay beyond reboot. See bin/tests/system/README for
details.
Security Fixes
9.8.0
None.
Bug Fixes
9.8.0
* BIND now builds with threads disabled in versions of NetBSD earlier
than 5.0 and with pthreads enabled by default in NetBSD versions
5.0 and higher. Also removes support for unproven-pthreads,
mit-pthreads and ptl2. [RT #19203]
* If BIND has openssl compiled in (the default) and has any
permission problems opening the openssl.cnf file, BIND utilities
fail. Currently ISC is including a patch to openssl in
bin/pkcs11/openssl-0.9.8l-patch but ISC is working on a better
solution until openssl fixes this. [RT #20668]
* nsupdate will now preserve the entered case of domain names in
update requests it sends. [RT #20928]
* Added a regression test for fix 2896/RT #21045 (rndc sign failed
to properly update the zone when adding a DNSKEY for publication
only). [RT #21324]
* nsupdate -l now gives error message if session.key file is not
found. [RT #21670]
* HPUX now correctly defaults to using /dev/poll, which should
increase performance. [RT #21919]
* If named is running as a threaded application, after an rndc stop
command has been issued, other inbound TCP requests can cause named
to hang and never complete shutdown. [RT #22108]
* After an rndc reconfig, the refresh timer for managed-keys is
ignored, resulting in managed-keys not being refreshed until named
is restarted. [RT #22296]
* An NSEC3PARAM record placed inside a zone which is not properly
signed with NSEC3 could cause named to crash, if changed via
dynamic update. [RT #22363]
* rndc -h now includes loadkeys option. [RT #22493]
* When performing a GSS-TSIG signed dynamic zone update, memory could
be leaked. This causes an unclean shutdown and may affect
long-running servers. [RT #22573]
* A bug in NetBSD and FreeBSD kernels with SO_ACCEPTFILTER enabled
allows for a TCP DoS attack. Until there is a kernel fix, ISC is
disabling SO_ACCEPTFILTER support in BIND. [RT #22589]
* When signing records, named didn't filter out any TTL changes to
DNSKEY records. This resulted in an incomplete key set. TTL changes
are now dealt with before signing. [RT #22590]
* Corrected a defect where a combination of dynamic updates and zone
transfers incorrectly locked the in-memory zone database, causing
named to freeze. [RT #22614]
* Don't run MX checks (check-mx) when the MX record points to ..
[RT #22645]
* DST key reference counts can now be incremented via dst_key_attach.
[RT #22672]
* The IN6_IS_ADDR_LINKLOCAL and IN6_IS_ADDR_SITELOCAL macros in win32
were updated/corrected per current Windows OS. [RT #22724]
* dnssec-settime -S no longer tests prepublication interval
validity when the interval is set to 0. [RT #22761]
* isc_mutex_init_errcheck() in phtreads/mutex.c failed to destroy
attr. [RT #22766]
* The Kerberos realm was being truncated when being pulled from the
the host prinicipal, make krb5-self updates fail. [RT #22770]
* Fixed GSS TSIG test problems for Solaris/MacOSX. [RT #22853]
* named failed to preserve the case of domain names in RDATA which is
not compressible when writing master files. [RT #22863]
* The man page for dnssec-keyfromlabel incorrectly had -U rather
than the correct option -I. [RT #22887]
* The rndc command usage statement was missing the -b option. [RT
#22937]
* The TTL for DNS64 synthesized answers was not always set correctly.
[RT #23034]
* The secure zone update feature in named is based on the zone being
signed and configured for dynamic updates. A bug in the ACL
processing for allow-update { none; }; resulted in a zone that is
supposed to be static being treated as a dynamic zone. Thus, name
would try to sign/re-sign that zone erroneously. [RT #23120]
Known issues in this release
* None.
Thank You
Thank you to everyone who assisted us in making this release possible.
If you would like to contribute to ISC to assist us in continuing to
make quality open source software, please visit our donations page at
http://www.isc.org/supportisc.
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind
Re: migration bind8/bind9: config problems.
Firstly please get your mail client fixed. Turning comma's to =2C isn't needed and defeats the purpose of printed quotable which is to do the minimum changes to make the message transmitable via 7bit smtp so that the message is readable by old clients. Anything above that minimum is a bug. In message col105-w610d1e1f6dce88a566c29fac...@phx.gbl, hugo hugoo writes: Dear all, I am testing an upgrade from bind8 to bind9. For this, I have installed bind9 in a server with the same configuration files as present in the server running bind8. When I start bind9, I have the following errors and the server do not sta rt. Can you anyone answer the questions presnet in the log here aboive to help me with my migration? Thanks in advance, Hugo, eb 15 13:13:10 dnsextcache001 named[17541]: starting BIND 9.6-ESV-R3 -c /et c/bind/named.conf Feb 15 13:13:10 dnsextcache001 named[17541]: built with '--prefix=/usr/lo cal/bind-9.6-ESV-R3' Feb 15 13:13:10 dnsextcache001 named[17541]: using up to 4096 sockets Feb 15 13:13:10 dnsextcache001 named[17541]: loading configuration from '/e tc/bind/named.conf' Feb 15 13:13:10 dnsextcache001 named[17541]: /etc/bind/named.conf:17: optio n 'fetch-glue' is obsolete == can I remove this from the configuration without any impact? Yes. It can be safely removed. Feb 15 13:13:13 dnsextcache001 named[17541]: loading configuration: failure Feb 15 13:13:13 dnsextcache001 named[17541]: exiting (due to fatal error) Feb 15 13:13:13 dnsextcache001 named[17541]: /etc/bind/conf/named.zones.inc :488832: zone 'thermote-vanhalst.com': already exists previous definition: /etc/bind/conf/named.zones.inc:93105 Feb 15 13:13:13 dnsextcache001 named[17541]: /etc/bind/conf/named.zones.inc :489192: zone 'villedewavre.be': already exists previous definition: /etc/b ind/conf/named.zones.inc:104087 Feb 15 13:13:13 dnsextcache001 named[17541]: /etc/bind/conf/named.zones.inc :489912: zone 'saval.be': already exists previous definition: /etc/bind/con f/named.zones.inc:186169 Feb 15 13:13:13 dnsextcache001 named[17541]: /etc/bind/conf/named.zones.inc :490816: zone 'dataminercube.com': already exists previous definition: /etc /bind/conf/named.zones.inc:384171 Feb 15 13:13:13 dnsextcache001 named[17541]: /etc/bind/conf/named.zones.inc :491735: zone 'cdmeerhout.be': already exists previous definition: /etc/bin d/conf/named.zones.inc:179099 Feb 15 13:13:13 dnsextcache001 named[17541]: /etc/bind/conf/named.zones.inc :491745: zone 'agroservices.be': already exists previous definition: /etc/b ind/conf/named.zones.inc:291937 Feb 15 13:13:13 dnsextcache001 named[17541]: loading configuration: failure Feb 15 13:13:13 dnsextcache001 named[17541]: exiting (due to fatal error) == I can remove the duplicates to allow bind9 to start (bind8 starts even if duplicates present). BUT!! I would like to have for this point the same behaviour as bind8 as it is po ssible that the provisioning in hte future introduces duplicates as it is t he case in my present setup. Is this possible? No. Run the configuration through named-checkconf if you are worried. It will catch the duplicates before you run named. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: migration bind8/bind9: config problems.
In message col105-w177d907c41a3b909556c83ac...@phx.gbl, hugo hugoo writes: Does exist a tool to automaticaly remove the duplicates in the configuratio= n? No. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: [SOLVED] Re: BIND9 SERVFAIL on some .gov addresses
: Server is not an authority for = domain/P P ..0. =3D Truncated: Message is not truncated/P P ...0 =3D Recursion desired: Don't do query = recursively/P P 0... =3D Recursion available: Server can't do = recursive=20 queries/P P .0.. =3D Z: reserved (0)/P P ..0. =3D Answer authenticated: Answer/authority = portion was not=20 authenticated by the server/P P =3D Reply code: No error (0)/P PQuestions: 1/P PAnswer RRs: 0/P PAuthority RRs: 6/P PAdditional RRs: 1/P PQueries/P Pvwall4a.nyc.gov: type A, class IN/P PName: vwall4a.nyc.gov/P PType: A (Host address)/P PClass: IN (0x0001)/P PAuthoritative nameservers/P Pnyc.gov: type NS, class IN, ns vwall1a.nyc.gov/P PName: nyc.gov/P PType: NS (Authoritative name server)/P PClass: IN (0x0001)/P PTime to live: 1 day/P PData length: 10/P PName server: vwall1a.nyc.gov/P Pnyc.gov: type NS, class IN, ns vwall2a.nyc.gov/P PName: nyc.gov/P PType: NS (Authoritative name server)/P PClass: IN (0x0001)/P PTime to live: 1 day/P PData length: 10/P PName server: vwall2a.nyc.gov/P Pnyc.gov: type NS, class IN, ns vwall3a.nyc.gov/P PName: nyc.gov/P PType: NS (Authoritative name server)/P PClass: IN (0x0001)/P PTime to live: 1 day/P PData length: 10/P PName server: vwall3a.nyc.gov/P Pnyc.gov: type NS, class IN, ns vwall4a.nyc.gov/P PName: nyc.gov/P PType: NS (Authoritative name server)/P PClass: IN (0x0001)/P PTime to live: 1 day/P PData length: 10/P PName server: vwall4a.nyc.gov/P Prq2651faaj4nen6tfis8ju5005qccn8j.gov: type Unknown (50), class IN/P PName: rq2651faaj4nen6tfis8ju5005qccn8j.gov/P PType: Unknown (50)/P PClass: IN (0x0001)/P PTime to live: 1 day/P PData length: 35/P PData/P Prq2651faaj4nen6tfis8ju5005qccn8j.gov: type RRSIG, class IN/P PName: rq2651faaj4nen6tfis8ju5005qccn8j.gov/P PType: RRSIG (RR signature)/P PClass: IN (0x0001)/P PTime to live: 1 day/P PData length: 279/P PType covered: Unknown (50)/P PAlgorithm: Unknown (0x07)/P PLabels: 2/P POriginal TTL: 1 day/P PSignature expiration: Feb 22, 2011 05:00:22.0/P PTime signed: Feb 17, 2011 05:00:22.0/P PId of signing key(footprint): 47602/P PSigner's name: gov/P PSignature/P PAdditional records/P Plt;Rootgt;: type OPT/P PName: lt;Rootgt;/P PType: OPT (EDNS0 option)/P PUDP payload size: 1472/P PHigher bits in extended RCODE: 0x0/P PEDNS0 version: 0/P PZ: 0x0/P PData length: 0/P/SPAN/SPAN/DIV/BODY/HTML --=_NextPart_000_0116_01CBCF84.31A5E720-- --===7478579667512691322== Content-Type: text/plain; charset=us-ascii MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users --===7478579667512691322==-- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: bind and IPV6
In message col105-w82277b2db4a69dc3d102fac...@phx.gbl, hugo hugoo writes: Dear all, In the scope of the IPV6 deployment, I have been asked if oiyr DNS server s are IPV6 compliant. We are now upgrading all our servers to bind-9.6-ESV-R3. - Can anybody give some feedback on the IPV6 compliancy? IS bind-9.6-ESV-R3 totally compliant with IPV6? Yes. Thanks in advance to share your experience/knowledge. Regards, Hugo, = -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: [SOLVED] Re: BIND9 SERVFAIL on some .gov addresses
In message 0539E64AD2B54AD2804C2394F923800B@se179, Shaoquan Lin writes: Mark, Are these bugs (2784 and 1804) fixed by BIND 9.6.1-P3? My problem is that I can not get A records of NSs (like vwall4a.nyc.gov) of nyc.gov from b.gov-servers.net by BIND 9.6.1-P3 but with no problem with older BINDs like 9.3. I don't know if the problem is with the authoritative nameservers for gov or the nameservers for nyc.gov or with the BIND I am using. I noticed the following: Just fix your firewalls to allow EDNS responses through. While this is a bug in the authoritative servers / interpretation of RFC 1034, its only a issue because your firewall configuration is a decade out of date that it is a problem. 1). a.gov-servers.net or b.gov-servers.net does provide A records in the additional records of their responses for other subdomain under gov like treas.gov, just not nyc.gov. So the problem seems with nameservers for nyc.gov. The problem is relatively new and there might be some recent changes on nyc.gov. The gov servers will return glue if you let bigger answers than 512 bytes through your firewall. ; DiG 9.6.0-APPLE-P2 +norec vwall4a.nyc.gov @b.gov-servers.net +dnssec ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 50028 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 5 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1472 ;; QUESTION SECTION: ;vwall4a.nyc.gov. IN A ;; AUTHORITY SECTION: nyc.gov.86400 IN NS vwall1a.nyc.gov. nyc.gov.86400 IN NS vwall2a.nyc.gov. nyc.gov.86400 IN NS vwall3a.nyc.gov. nyc.gov.86400 IN NS vwall4a.nyc.gov. rq2651faaj4nen6tfis8ju5005qccn8j.gov. 86400 IN NSEC3 1 0 8 4C44934802D3 RQDJO8PKJ2LEUMC30SGU45DDI643G497 NS rq2651faaj4nen6tfis8ju5005qccn8j.gov. 86400 IN RRSIG NSEC3 7 2 86400 20110227210022 2011010022 47602 gov. ENl60LTdlJfmyDp9wrwh6bQao8TvqTk8hX4qD6x4bHGBixjsGhOy/si8 JVUl1MbeJ1PaJ3p59/ABFUv7ApOh5v6eflzhsBa6EalBrYCC5HpOabJn Q2r0RFqDvUb1Qo921cnbC+3Bh37i3DVTbK+poYpIkbpJAxOE+/zp/PrA 1L0v2kuS9t6gHLk+ZzfsQI6Gi9Ezg2VZIhVXGz06a7EzyGy2BZ/Plz4u In2Dj5ncwAlAi9dC6xiQTW2yRmVSQoXzNZKUcZO+E0mPKPR9DcNVotX9 CzTbrOyKNtYrrV6GNslN5qicuHIehriQIMPdXs3/e2ZhB3h944kpymqL ag3tCg== ;; ADDITIONAL SECTION: vwall1a.nyc.gov.86400 IN A 161.185.1.3 vwall2a.nyc.gov.86400 IN A 161.185.1.12 vwall3a.nyc.gov.86400 IN A 167.153.130.12 vwall4a.nyc.gov.86400 IN A 167.153.130.13 ;; Query time: 187 msec ;; SERVER: 209.112.123.30#53(209.112.123.30) ;; WHEN: Wed Feb 23 11:54:06 2011 ;; MSG SIZE rcvd: 574 2) Older version of Binds (like 9.3) seems able to resolve vwall4a.nyc.gov as shown the packets I captured in my previous e-mail. What options in named.conf I can use to set tc? Thank you. Shaoquan Lin -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: inconsistency dnssec debuguers response and writing conseil for new areas zone
In message 1299012754.7.430.camel@localhost.localdomain, fakessh @ writ es: as I now know what key DS uses. I logged into my account and I moved isc dlv record SHA1 DS, and I thought to receive a new record or something like that. well no reply from the ISC is : A corresponding DNSKEY already exists for this record. Because there are already DLV records for the key in the DLV. ;; ANSWER SECTION: fakessh.eu.dlv.isc.org. 3529IN DLV 47103 3 2 68096942650C1DD89D5BE43A9EEA05BA9C20F09EDC55309F4F1CD348 4D8ED07B fakessh.eu.dlv.isc.org. 3529IN DLV 47103 3 1 CFEA04C5B918359273D6BAC07AE7F2DF5225E357 And the zone itself validates (ad=1). ; DiG 9.6.0-APPLE-P2 fakessh.eu soa +adflag ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 4080 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;fakessh.eu.IN SOA ;; ANSWER SECTION: fakessh.eu. 38400 IN SOA r13151.ovh.net. postmaster.fakessh.eu. 2011022802 10800 3600 604800 38400 ;; Query time: 2521 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Wed Mar 2 08:45:13 2011 ;; MSG SIZE rcvd: 89 All comments are welcome to help me find a solution nb : I publish on my blog a little article on dnssec http://fakessh.eu/2011/02/16/faire-marcher-dnssec-sur-son-serveur/ Le mardi 01 mars 2011 =C3=A0 21:00 +0100, Torinthiel a =C3=A9crit : On 03/01/11 20:17, fakessh @ wrote: is the repeat isc dlv seems to accept the flag DS in my case i have to a file dsset-fakessh.eu but the file contains two keys DS and i don't know which to use The DS you have are both for the same key, only one is SHA1 and other SHA256. You could try any of them, but see below. ISC DLV accepts keys, you have to create an account, add your zone and keys for it. I remember having some trouble trying to add DS records, but DNSKEY worked fine. Of course the zone has to be signed using that key, and ISC asks you to add a TXT record at dlv.your.zone (or something similar) to prove your ability to modify the zone. The procedure is simple and well defined. And about OVH - I don't know if it's related, but I've asked Polish OVH how about providing DNSSEC, as .pl is planned to be signed mid-year, and they've answered me they will probably be ready. This might, or might not be related to providing DNSSEC by other OVH branches and for other registries. Torinthiel ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- gpg --keyserver pgp.mit.edu --recv-key 092164A7 http://pgp.mit.edu:11371/pks/lookup?op=3Dgetsearch=3D0x092164A7 --=-hAV62QMSnDEL5t7IF2op Content-Type: application/pgp-signature; name=signature.asc Content-Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?= -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQBNbVyStXI/OwkhZKcRApHLAJ9mpVDpLbdoXNJE2HWrZtEMP5nkOQCfQHxF OWD+2cnsCQvmY1sJsLmpZoA= =3tB9 -END PGP SIGNATURE- --=-hAV62QMSnDEL5t7IF2op-- --===8423262514623441036== Content-Type: text/plain; charset=us-ascii MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users --===8423262514623441036==-- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Help with unresolvable domain (subdomain, actually)
In message 4d6d7268.1080...@chrysler.com, Kevin Darcy writes: I got a trouble ticket on this too. From the looks of things, Cisco is using GSSes to load-balance this site. GSSes return SERVFAIL if all of the resources behind the load-balancer are down (which it determines via a heartbeat mechanism). So I think this is a simple case of a website (or cluster) going down. It was down earlier today, then up again, as of this writing, it is down again. DNS doesn't really have a response code of requested resource not available, so SERVFAIL is Cisco's closest approximation. It has the drawback, however, of often making other sorts of problems appear to be DNS problems. That's just a cross that we DNS admins have to bear... - Kevin Then the load balancer should return default records or 0.0.0.0/:: to indicate the name is good but doesn't currently have a address. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: about AUTHORITY SECTION
In message AANLkTi=9B07Q=flysn6s-0scossneuxms0qgy9h+o...@mail.gmail.com, terr y writes: Hello, When I delegate a subdomain in a zone example.com, the config in named.conf is like: test.example.com. 3600 IN NS ns1.another.com. test.example.com. 3600 IN NS ns2.another.com. Then I dig to the auth-server of the example zone: dig test.example.com ns @ns1.example.com I found some servers return the ANSWER SECTION, but some servers return the AUTHORITY SECTION. For example: ;; ANSWER SECTION: test.example.com. 3600IN NS ns2.another.com. test.example.com. 3600IN NS ns1.another.com. And: ;; AUTHORITY SECTION: test.example.com. 3600IN NS ns2.another.com. test.example.com. 3600IN NS ns1.another.com. I'm confused, shall name server answer with ANSWER or AUTHORITY for this case ? Look at RA and RD. If the server recurses, you will get a answer. If the server does not recurse, you will get a referral. Then there are the really old broken servers which get this wrong. Mark Thanks in advance. ___ 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 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Slaves and views
In message 79391b3d-6106-420b-9056-717a5e5fa...@cornell.edu, John Wobus write
s:
Hi,
Can a zone file a slave in one view and the same zone file
be served by another view?
I'm going to split our authoritative servers into internal
and external views. My question concerns zones that we
secondary for other organizations, slaved to masters at
their sites.
I know I could configure each of their zones with separate files
in each the two views, listen/use an additional address that
accesses our local view, and tell these peer organizations to
notify and allow transfers from this additional address.
I'm not (yet) worried about dynamic updates, if there are
any.
Is there a way I can handle their zones without making
these other sites configure another address, and I still
run just one bind instance?
Other ideas are: running a separate bind instance for
these zones, or making one view a slave to the other.
Possibly forwarding of some kind, another thing I haven't
done much.
John Wobus
Cornell
Any file named writes, slave, dynamic master, should not be shared.
That said you don't need to change how zone are transfered between
you and the master. You can just transfer them internally from
one view to the other.
key external.key {
};
acl internal-clients {
...
127.0.0.1;
};
view internal {
match-clients {
!key external.key;
internal-clients;
};
zone example {
type slave;
file slave/internal/example;
masters { 127.0.0.1 key external.key; };
};
};
view external {
match-clients {
key external.key;
any;
};
zone example {
type slave;
file slave/external/example;
masters { };
allow-transfer { external.key; };
also-notify { 127.0.0.1; };
};
};
___
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
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: different behavior: A Records in DNS answer, when query of type any (existing CNAME)
In message 1dd28595e6555e498a4eed9cf13f8abf07be207...@svcstccrmb01.devoteam.co m, Diezig Adrian writes: Hi, I have a question concerning answers from DNS servers, when I query a name = with type any and the name is a CNAME. I have the following example (works also in Internet) with an ISC BIND serv= er (BIND 9.7.0-P1): ; DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_4.2 @newton.genesiscom.ch dn= s.ipam.ch ; (1 server found) ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 25078 ;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;dns.ipam.ch. IN A ;; ANSWER SECTION: dns.ipam.ch.600 IN CNAME www.ipam.ch. www.ipam.ch.600 IN A 81.18.25.238 ;; Query time: 1 msec ;; SERVER: 10.10.3.13#53(10.10.3.13) ;; WHEN: Mon Mar 7 11:52:38 2011 ;; MSG SIZE rcvd: 63 As you can see, we have a CNAME dns.ipam.ch that points to www.ipam.ch. www.ipam.ch is an A-Record to 81.18.25.238. When I do the following query (type=any to dns.ipam.ch), only the CNAME i= tself will be in the answer section (the A-Record not): ; DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_4.2 @newton.genesiscom.ch dn= s.ipam.ch any ; (1 server found) ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 46532 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;dns.ipam.ch. IN ANY ;; ANSWER SECTION: dns.ipam.ch.600 IN CNAME www.ipam.ch. ;; Query time: 1 msec ;; SERVER: 10.10.3.13#53(10.10.3.13) ;; WHEN: Mon Mar 7 11:53:21 2011 ;; MSG SIZE rcvd: 47 When I do a comparable query (also with type=any) to another DNS Server (= eg. google.com) ; DiG 9.3.2 @ns1.google.com. www.google.com. any ; (1 server found) ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 1636 ;; flags: qr aa rd; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.google.com.IN ANY ;; ANSWER SECTION: www.google.com. 604800 IN CNAME www.l.google.com. www.l.google.com. 300 IN A 74.125.232.114 www.l.google.com. 300 IN A 74.125.232.115 www.l.google.com. 300 IN A 74.125.232.116 www.l.google.com. 300 IN A 74.125.232.113 www.l.google.com. 300 IN A 74.125.232.112 ;; Query time: 46 msec ;; SERVER: 216.239.32.10#53(216.239.32.10) ;; WHEN: Mon Mar 07 09:44:32 2011 ;; MSG SIZE rcvd: 132 ... I will get also the associated A Records. Does anybody have an idea, why the behavior is different? Can I configure t= his on my DNS Server (ISC BIND)? FYI: dig @ns1.hp.com. www.hp.com. any and dig @ns1.yahoo.com. www.yahoo.com any will also answer without any A-Records (like me). I have the following questions: - which one is correct (RFC)? - is it configurable in ISC BIND? - does the behavior depends on different BIND version? I know that it is not very common to do queries with type any. The problem = we have is the following: A Device/Application in our network is doing always queries from type any= . From our side it's not possible to change the type, because it's hard-coded= in the software. Go back to your vendor and demand a fix. Applications which make ANY queries and don't followup with specific type the application needs when it isn't returned are broken. ANY queries are handled differently to normal queries. Similarly CNAME queries are handled differently to normal queries. Mark Kind regards Adrian -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: IXFR manually edited zone files
In message b840935f-4809-40cf-98c5-029cbbab4...@columbia.edu, David Coulthart
writes:
On Mar 7, 2011, at 12:24 PM, David Coulthart wrote:
On Mar 7, 2011, at 11:42 AM, Chris Thompson wrote:
On Mar 7 2011, David Coulthart wrote:
BIND Version: 9.7.3 on Solaris 9 10 (locally compiled)
...
Based on the ARM a posting to bind-users[1], I enabled ixfr-from-diffe
rences
master; on the hidden master expecting the master nameserver would gener
ate
a diff from the previous zone file in memory and the new one being load
ed
so it could send an IXFR to the slaves.
...
There is also a named-journalprint utility which you can apply to the
journal file on the master to check it contains what you hope for.
I don't see a journal file being created on the master after I do the reloa
d. The only messages in the master's log about a journal are on initial star
tup:
...
Based on the description of ixfr-from-differences in the ARM, I think a jou
rnal file should be created. I have named running as user named, but I've ch
ecked permissions on the directory zone file confirmed that named can cre
ate files in the directory containing the zone file.
It looks like the problem is with setting ixfr-from-differences to master. I
f I instead set the option to yes, a journal file is generated IXFR works c
orrectly. The zone definition in my test named.conf is:
zone example.com {
type master;
file example.com.zone;
};
so I expected setting ixfr-from-differences master; would cause a journal f
ile to be created for this master zone. Am I not understanding what the mast
er option for ixfr-from-differences is intended to do or is this a bug in BIN
D?
Thanks,
Dave Coulthart
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Index: bin/named/zoneconf.c
===
RCS file: /proj/cvs/prod/bind9/bin/named/zoneconf.c,v
retrieving revision 1.171.34.2
diff -u -r1.171.34.2 zoneconf.c
--- bin/named/zoneconf.c7 Mar 2011 04:16:39 - 1.171.34.2
+++ bin/named/zoneconf.c8 Mar 2011 20:44:00 -
@@ -1077,10 +1077,10 @@
INSIST(result == ISC_R_SUCCESS obj != NULL);
if (cfg_obj_isboolean(obj))
ixfrdiff = cfg_obj_asboolean(obj);
- else if (strcasecmp(cfg_obj_asstring(obj), master)
+ else if (!strcasecmp(cfg_obj_asstring(obj), master)
ztype == dns_zone_master)
ixfrdiff = ISC_TRUE;
- else if (strcasecmp(cfg_obj_asstring(obj), slave)
+ else if (!strcasecmp(cfg_obj_asstring(obj), slave)
ztype == dns_zone_slave)
ixfrdiff = ISC_TRUE;
else
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Reliability and performance on a simple caching BIND9 server for uncached queries
In message aanlktiku23pyyjizeddlmmoi7rwvbuxp8wxoudeow...@mail.gmail.com, Khou ry Brazil writes: Hi, I've noticed some speed and reliability issues with my BIND9 boxes relating to uncached external queries. External queries that return NX seem to be the worst offenders in these tests and are what I've focused on during my testing. I've confirmed it using a simple benchmarking tool called DNS Benchmark and some simple testing on my part. DNS Benchmark points out that my BIND9 boxes aren't reliable because lookup requests that are dropped and ignored by nameservers cause significant delays in Internet access to quote the software. DNS Benchmark compares your name servers against external name servers and it shows my boxes as 86% reliable compared to the general list (which includes the level 3 servers, Cox, Symantec, etc) which are, for the most part at 100%. I'm guessing this has to do with the software timing out. Doing a simple test using nslookup doing uncached external lookups (on ubuntu and one windows client): No delay using nslookup or dig directly from my bind boxes to the external name servers. This indicates to me that the bottle neck doesn't exist between my internal and ISP's name servers. No delay when using nslookup or dig from a client machine on my network to the external name servers. This indicates to me that the client isn't the issue. A long delay with ubuntu clients looking up against my internal BIND boxes; Timeouts with Windows and nslookup (due to its shorter timeout). Internal queries are fast using all of the above tests (the BIND box forwards to different internal name servers that are authoritative for our internal name space). This indicates to me that it isn't my bind boxes being slow in general. Is it normal to see slow responses when querying for uncached non-existent domains? I've noticed that other external queries could be faster, but these are really bad. When I query my internal bind boxes that are authoritative for my internal domain directly they respond instantly for NX domains. I don't admin those though so have no insight into their configuration beyond the fact that they run on some nix flavor and are BIND* boxes. Thanks for any insight. Try asking your ISP's nameserver with dig +dnssec. I suspect that your firewall/NAT doesn't handle the larger responses. ___ 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 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: necessary to have a secondary dns ipv6
In message 1300057854.8326.193.camel@localhost.localdomain, fakessh @ write s: hello bind guru and list How is it necessary to have a secondary dns ipv6 to properly establish a connection ipv6 thanks for your return If you want to be able to claim you are IPv6 ready you really need multiple servers reachable over IPv6 the same as you need multiple servers over IPv4. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Stub zone vs forward zone
In message 20110314104330.ga29...@torres.zugschlus.de, Marc Haber writes:
Hi,
I am running a local instance of bind on my notebook to spare myself
some rather annoying reconfiguration orgies that are bound to happen
when changing networks.
On my biggest customer's network, I am trying to be able to access
their reverse DNS, which is (don't ask) not loaded on the servers that
my notebook is assigned via DHCP as forwarders.
I have thus configured these zones locally, experimenting with
differnt configuration types:
zone 2.1.10.in-addr.arpa {
type stub;
masters { 10.1.2.11; 10.1.2.45; };
file stub/2.1.10.in-addr.arpa;
forwarders { };
};
zone 101.1.10.in-addr.arpa {
type forward;
forwarders { 10.1.101.6; };
forward only;
};
The stub zone works; the forward zone doesn't. When I ask my local
bind for 6.101.1.10.in-addr.arpa (PTR), I get an immediate NXDOMAIN
without bind even trying to talk to the actual name server.
I can ping 10.1.101.6 just fine.
I must admit that I haven't yet full understood the difference between
a stub zone and a forward zone, any why i need the forwarders { } on
the stub zone.
The empty forwarders clause turns off the enclosing/global forwarders.
Any hints will be appreciated.
Greetings
Marc
--
-
Marc Haber | I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany | lose things.Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190
___
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
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: A very Odd SOA Problem
In message 201103150326.p2f3qdfo049...@x.it.okstate.edu, Martin McCormick wri tes: We just moved one of our remote campuses to new IPv4 number space and I was having tremendous problems all day using nsupdate. I thought it was because the change of DNS address had not gone through yet, but it had and a whois lookup shows the correct DNS addresses. When I finally debugged an nsupdate attempt, I see what is happening but I am not sure why. Found zone name: 253.112.64.IN-ADDR.ARPa The master is: ns.osuit.edu Sending update to 164.112.255.20#53 That's our problem. A SOA query seems to be returning 164.112.255.20 but the proper address is 64.112.255.20 I thought I had fat-fingered an entry in the zone for osuit.edu, but if you query it for the SOA record, you get: osuit.edu.43200 IN SOA ns.osuit.edu. lisa.garrison.oks tate.edu. 908 3600 900 608400 30 osuit.edu.22697 IN NS ns2.osuit.edu. osuit.edu.22697 IN NS ns.osuit.edu. ns.osuit.edu. 7956IN A 64.112.255.20 ns2.osuit.edu.22697 IN A 64.112.255.21 Those addresses are correct and the whois data base was updated today with the same addresses. Name Servers: NS.OSUIT.EDU 64.112.255.20 NS2.OSUIT.EDU 64.112.255.21 I've been fighting this all day and have run out of ideas. nsupdate calls getaddrinfo() which uses /etc/hosts, NIS and DNS. Check /etc/hosts and NIS. Any ideas as to why the address is changing? I even did a recursive grep on the master for 164.112.255 and didn't find a thing matching that. thanks for any suggestions. this totally breaks nsupdate unless you force the server and zone information. Martin McCormick WB5AGZ Stillwater, OK Systems Engineer OSU Information Technology Department Telecommunications Services Group ___ 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 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Zones not getting transferred after a restart
In message ilo4hp$s5g$1...@dough.gmane.org, Bernhard Schmidt writes: Hi, we have an internal distribution point running BIND 9.5.0-P2 (SLES 11.1 distribution package). It slaves about 1800 zones from a commercial DNS management software running on 127.0.0.1:8054 and distributes them towards our servers. Whenever we restart BIND on that system, the 1800 zones are loaded within two seconds (1800 loaded serial x entries, running), but it takes up to 30 minutes (26 minutes the last time) where it does not do any AXFR upstream and logs 15-Mar-2011 09:36:47.334 zone kongress.xxx.de/IN: notify from 127.0.0.1#8054: refresh in progress, refresh check queued on every notify it receives. I cannot really see SOA queries upstream either. When that time has passed by it catches up with the zone transfers. Other than having edns no and request-ixfr no set for the upstream server (due to bugs in this field) the configuration is pretty standard. I'm not really opposed to updating the BIND to a newer version, but given I'd have to go away from the distribution package where I feel fine using it (firewalled system, only reachable by our other servers) I'd rather know for sure that this problem is solved. I see similar issues on our frontend servers running 9.7.3. Can anyone explain how I can speedup this progress? Disable notify for the zones. Increase soa-query-rate. It also applies to notifies. Also I'd like to disable/tune down the 15-Mar-2011 08:25:36.828 zone xxx.in-addr.arpa/IN: refresh: skipping zone transfer as master 127.0.0.1#8054 (source 0.0.0 .0#0) is unreachable (cached) thing. Good idea, but stopping all zone transfers for 10 minutes from the only master just because it was unreachable for a few seconds is a bad idea. Adjust lame-ttl. I have searched for a named.conf knob and have failed to find any. Closest I have found is serial-query-rate, which is not set in our environment and should default to 20. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Best ipfw Rules for DNS-SEC
In message 1200b563-8a00-4c0a-822d-85733143f...@mac.com, Chuck Swiger writes : On Mar 15, 2011, at 11:08 AM, Martin McCormick wrote: Is there a recommended set of firewall rules that insure that all necessary DNS traffic can enter and leave, even the larger packets that result from dns-sec? # allow UDP DNS queries out to the world, and in to your nameservers ## It's faster to do this stateless, and reduces DoS risk against the firewa ll, ## but you are exposing your network to UDP port scans from source port 53 ## (if you have other open UDP ports). If you want to be stateful, switch t o: ## add pass udp from any to $NAMESERVER_IP 53 keep-state ## add pass udp from $YOURNET to any 53 keep-state add pass udp from any to $NAMESERVER_IP 53 add pass udp from $NAMESERVER_IP 53 to any add pass udp from $YOURNET 53,1024-65535 to any 53 add pass udp from any 53 to $YOURNET 53,1024-65535 # allow TCP DNS outbound and inbound only to nameserver boxes ## Likewise, you can add keep-state if you want to be stateful; ## in which case the established line can be removed. add pass tcp from any to any established add pass tcp from $YOURNET to any 53 setup add pass tcp from any to $NAMESERVER_IP 53 setup -- For something like a Cisco PIX/ASA, you probably want no fixup protocol dns to avoid breaking EDNS, but fixup protocol dns maximum-length 4096 might be a workable alternative. You also want to pass UDP fragments. e.g. ipfw: add pass udp from any to any frag ipf: pass in quick proto udp from any to any with frag keep frag -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Best ipfw Rules for DNS-SEC
ISC has deployed two test zones with specially configured servers to support the testing of firewalls and EDNS. You can test the firewall rules using: dig edns-v4-ok.isc.org txt (IPv4) dig edns-v6-ok.isc.org txt (IPv6) These queries will only be successfully answered if there is a clean EDNS UDP path that supports a 4096 byte EDNS packet. The servers for these zones are setup to cause the query to fail if there is not a clean EDNS UDP path that supports a 4096 byte EDNS packet. Fall back to TCP is NOT supported on the servers for these zones. EDNS queries using UDP buffer sizes less than 4096 for these queries will NOT work. You can check that the caching server can reach the servers for the zones with: dig edns-v4-ok.isc.org soa (IPv4) dig edns-v6-ok.isc.org soa (IPv6) To query the servers directly you will need to specify +edns=0 or +dnssec with dig to get the TXT record. dig +dnssec edns-v4-ok.isc.org txt @edns-v4-ok.isc.org (IPv4) dig +dnssec edns-v6-ok.isc.org txt @edns-v6-ok.isc.org (IPv6) Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: FORMERR for wikipedia...
The nameservers for wikipedia.org are broken. They put the wrong SOA record in the negative response, wikipedia.org != wikimedia.org. M vs P wikipedia.org. 86400 IN NS ns0.wikimedia.org. wikipedia.org. 86400 IN NS ns1.wikimedia.org. wikipedia.org. 86400 IN NS ns2.wikimedia.org. ;; Received 146 bytes from 2001:500:f::1#53(d0.org.afilias-nst.org) in 201 ms wikimedia.org. 86400 IN SOA ns0.wikimedia.org. hostmaster.wikimedia.org. 2011031404 43200 7200 1209600 600 ;; Received 108 bytes from 91.198.174.4#53(ns2.wikimedia.org) in 335 ms The adminstrators of wikimedia.org were informed about this months ago but they don't seem to care. They fail to acknowledge the problem or to fix the problem. wikimedia.org are not alone in this. There are thousands on web sites that return the wrong answers to lookups. Meanwhile everyone wants resolver vendors to make the lookups work. We can't when the authoritative servers are broken. It time the users complained. Mark In message alpine.deb.2.02.1103161239300.19...@seatpost.its.uiowa.edu, Jay Fo rd writes: A recursive resolver of mine running BIND 9.7.3 logs many messages like: resolver: DNS format error from 208.80.152.130#53 resolving \ en.wikipedia.org/ for client ::1#33887: invalid response lame-servers: error (FORMERR) resolving 'en.wikipedia.org//IN': \ 208.80.152.130#53 I see this for a variety of domains, including wikipedia.org, yahoodns.net, officedepot.com, staples.com. I did some investigation, including sniffing the DNS traffic. The problematic case seems to be names which have CNAMEs to names in other zones for which the queried record type doesn't exist. For example: en.wikipedia.org is a CNAME - text.wikimedia.org text.wikimedia.org is a CNAME - text.pmtpa.wikimedia.org text.pmtpa.wikimedia.org has an A record, but no , TXT... A query for type= name=en.wikipedia.org returns: % dig -t en.wikipedia.org ; DiG 9.7.3 -t en.wikipedia.org ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: SERVFAIL, id: 45218 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;en.wikipedia.org. IN ;; Query time: 229 msec ;; SERVER: ::1#53(::1) ;; WHEN: Wed Mar 16 11:34:08 2011 ;; MSG SIZE rcvd: 34 The response packet from the wikipedia/wikimedia DNS servers is: Internet Protocol, Src: 208.80.152.142 (208.80.152.142), \ Dst: 128.255.204.16 (128.255.204.16) User Datagram Protocol, Src Port: 53 (53), Dst Port: 55497 (55497) Domain Name System (response) [Request In: 159] [Time: 0.061065000 seconds] Transaction ID: 0xd49c Flags: 0x8400 (Standard query response, No error) Questions: 1 Answer RRs: 0 Authority RRs: 1 Additional RRs: 0 Queries en.wikipedia.org: type , class IN Authoritative nameservers wikimedia.org: type SOA, class IN, mname ns0.wikimedia.org so, basically: code NOERROR no answer authority citing wikimedia.org NOERROR seems right, but it includes authority information for the zone of the CNAME target without including the CNAME as an answer, amounting to a mismatch between the original query the cited authority. Note that if I do an A query first, I get the CNAME via a correctly formed response, after which the TXT queries work, with the CNAME chain filled in from local cache. To me it looks like BIND is doing the right thing (as usual ;^), but the wikipedia... servers are returning bogus responses. Is this interpretation correct? If so, does anybody know what apparently screwy DNS server or configuration causes this behavior? I saw something similar with an F5 installation here on campus briefly before I had the local folks fix it, but I'd like some confirmation that's what's going on with wikipedia... before I try to get them others to fix it. Further, if it's a systemic F5... problem, then a different approach is probably in order. Jay Ford, Network Engineering Group, Information Technology Services University of Iowa, Iowa City, IA 52242 email: jay-f...@uiowa.edu, phone: 319-335-, fax: 319-335-2951 ___ 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 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Need help to know about ROOT DNS query
In message 8423.3972...@web137314.mail.in.yahoo.com, babu dheen writes: Hi, Thanks for the response. But i read a article in sans.org website that inte= rnal DNS server should not respond to ROOT NS query. Please find the below URL for more information. http://isc1.sans.org/dnstest.html http://isc.sans.edu/diary.html?storyid=5713 Kindly help me. The query is being used to determine if the nameserver is offing recursive services to machines it shouldn't. There isn't anything wrong the query itself or to returning the NS records if the machine should be getting recursive service. --- On Thu, 17/3/11, Warren Kumari war...@kumari.net wrote: From: Warren Kumari war...@kumari.net Subject: Re: Need help to know about ROOT DNS query To: babu dheen babudh...@yahoo.co.in Cc: bind-users@lists.isc.org bind-users@lists.isc.org Date: Thursday, 17 March, 2011, 8:50 PM Nah, that's fine (and normal). BIND comes configured with the roots so that it can start resolution. I gue= ss I don't fully understand your concern here -- is it that you are worried= that the root might see queries and so know your internal hostnames? W Warren Kumari --Please excuse typing, etc -- This was sent from a device with a tiny = keyboard. On Mar 17, 2011, at 7:20 AM, babu dheen babudh...@yahoo.co.in wrote: Hi, We have two internal Windows DNS servers which answer all DNS query by f= orwarding it to gateway DNS server running in Redhat BIND. But i have a que= ry regarding allowing ROOT DNS query on internal DNS server. Can anyone let me know whether company Internal DNS server should respond t= o ROOT DNS query. When i execute # dig . NS @my-company-name-server query= I am getting complete response Let me know whether enabling ROOT DNS query is a security threat. For mo= re informaton can you read and help us to securely configure our company in= ternal Windows DNS server and its impact of disabling it. ; DiG 9.3.3rc2 . NS @10.0.0.1 ; (1 server found) ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 34899 ;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 10 ;; QUESTION SECTION: ;.= IN NS ;; ANSWER SECTION: . 49842= IN NS j.root-servers.net. . 49842= IN NS k.root-servers.net. . 49842= IN NS l.root-servers.net. . 49842= IN NS m.root-servers.net. . 49842= IN NS a.root-servers.net. . 49842= IN NS b.root-servers.net. . 49842= IN NS c.root-servers.net. . 49842= IN NS d.root-servers.net. . 49842= IN NS e.root-servers.net. . 49842= IN NS f.root-servers.net. . 49842= IN NS g.root-servers.net. . 49842= IN NS h.root-servers.net. . 49842= IN NS i.root-servers.net. ;; ADDITIONAL SECTION: j.root-servers.net. 49842 IN A= 192.58.128.30 a.root-servers.net. 49842 IN A= 198.41.0.4 b.root-servers.net. 49842 IN A= 192.228.79.201 c.root-servers.net. 49842 IN A= 192.33.4.12 d.root-servers.net. 49842 IN A= 128.8.10.90 e.root-servers.net. 49842 IN A= 192.203.230.10 f.root-servers.net. 49842 IN A= 192.5.5.241 g.root-servers.net. 49842 IN A= 192.112.36.4 h.root-servers.net. 49842 IN A= 128.63.2.53 i.root-servers.net. 49842 IN A= 192.36.148.17 ;; Query time: 34 msec ;; SERVER: 10.0.0.1#53(10.132.1.13) ;; WHEN: Thu Mar 17 17:16:18 2011 ;; MSG SIZE rcvd: 401 ___ 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 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: ip6.arpa help
You could just put the customer zones on a separate nameserver and let the clients dynamically update the zones. Windows will do this automatically. Named has 6to4-self and tcp-self which use TCP as the authenticator. 6to4-self lets any machine in the /48 update records for any other machine in the /48. tcp-self just lets the machine update its records. Adding 56-self and 60-self would be relatively straight forward. Named also has external match. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: problem validate key of isc dlv
In message 1300650238.6651.15.camel@localhost.localdomain, fakessh @ writes : hello bind network and duru. I can not validate the key dlv via the website of the isc. I do not understand why the warning is the isc you have an explanation SUCCESS 94.23.59.30 answered DNSKEY query with rcode NOERROR 4.502:SUCCESS 87.98.164.164 answered DNSKEY query with rcode NOERROR 4.502:SUCCESS 87.98.186.232 answered DNSKEY query with rcode NOERROR 4.502:INFO Total answers: 3 4.503:DEBUG COMPARE: Comparing results from 94.23.59.30 to 87.98.164.164 4.504:DEBUG COMPARE: Comparing results from 94.23.59.30 to 87.98.186.232 4.504:SUCCESS All DNSKEY responses are identical. 4.515:DEBUG VERIFY-DNSKEY: Checking tag=10231 flags=257 alg=RSASHA1 AwEAAbwO...8fkjXphfS8= 4.515:DEBUG VERIFY-DNSKEY: Ignoring key. 4.515:DEBUG VERIFY-DNSKEY: Checking tag=30111 flags=256 alg=RSASHA1 AwEAAb1q...jG+UQeAtYE= 4.515:DEBUG VERIFY-DNSKEY: Ignoring key. 4.515:INFO VERIFY-DNSKEY: 2 DNSKEYs found. 4.515:INFO VERIFY-DNSKEY: 0 keys found after filtering. 4.515:DEBUG VERIFY-DNSKEY: Using keys: 4.516:DEBUG VERIFY-DNSKEY: To verify rrset type DNSKEY 4.516:FAILURE VERIFY-DNSKEY: No keys found after filtering. 4.516:FAILURE DNSKEY signature did not validate. 4.516:FINAL_FAILURE FAILURE Based on the key tags and the truncated keys I think these keys are for fakessh.eu and if so there isn't a DLV record or a DS published for fakessh.eu. The only other thing the validator can check against is any installed trust-anchor. Mark ; DiG 9.6.0-APPLE-P2 fakessh.eu.dlv.isc.org dlv ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 48161 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ; DiG 9.6.0-APPLE-P2 fakessh.eu ds ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 63623 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 -- gpg --keyserver pgp.mit.edu --recv-key 092164A7 http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x092164A7 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: problem validate key of isc dlv
In message 1300660825.6651.21.camel@localhost.localdomain, fakessh @ writes : Le dimanche 20 mars 2011 =C3=A0 22:47 +0100, Torinthiel a =C3=A9crit : On 03/20/11 22:33, fakessh @ wrote: and what do I do.=20 =20 You have to add your key to ISC's DLV registry. Go to dlv.isc.org, create account, login, add a zone, add keys for it and publish a record in your zone validating that you're the owner of the zone. You will be told what to do after you create zone. =20 that's what I did I made =E2=80=8B=E2=80=8Ba post on my blog explaining how I do goo.gl/EAbCB Have you changed your DNSKEY's since you did that? If you have did you update the zone in your account on dlv.isc.org? What does dlv.isc.org have to say about fakessh.eu? and what is this other publication of another DS In the end you should have a DS RRset published in the .EU zone for fakessh.EU. .EU claim to implement DNSSEC and that should mean that you can get DS records addeded for your zone. I have no idea what do you mean by this sentence. Torinthiel =20 =20 =20 Le lundi 21 mars 2011 =C3=A0 08:25 +1100, Mark Andrews a =C3=A9crit : In message 1300650238.6651.15.camel@localhost.localdomain, fakessh = @ writes : hello bind network and duru.=20 I can not validate the key dlv via the website of the isc.=20 I do not understand why the warning is the isc=20 you have an explanation SUCCESS 94.23.59.30 answered DNSKEY query with rcode NOERROR 4.502:SUCCESS 87.98.164.164 answered DNSKEY query with rcode NOERROR 4.502:SUCCESS 87.98.186.232 answered DNSKEY query with rcode NOERROR 4.502:INFO Total answers: 3 4.503:DEBUG COMPARE: Comparing results from 94.23.59.30 to 87.98.164.= 164 4.504:DEBUG COMPARE: Comparing results from 94.23.59.30 to 87.98.186.= 232 4.504:SUCCESS All DNSKEY responses are identical. 4.515:DEBUG VERIFY-DNSKEY: Checking tag=3D10231 flags=3D257 alg=3DRSA= SHA1 AwEAAbwO...8fkjXphfS8=3D 4.515:DEBUG VERIFY-DNSKEY: Ignoring key. 4.515:DEBUG VERIFY-DNSKEY: Checking tag=3D30111 flags=3D256 alg=3DRSA= SHA1 AwEAAb1q...jG+UQeAtYE=3D 4.515:DEBUG VERIFY-DNSKEY: Ignoring key. 4.515:INFO VERIFY-DNSKEY: 2 DNSKEYs found. 4.515:INFO VERIFY-DNSKEY: 0 keys found after filtering. 4.515:DEBUG VERIFY-DNSKEY: Using keys: 4.516:DEBUG VERIFY-DNSKEY: To verify rrset type DNSKEY 4.516:FAILURE VERIFY-DNSKEY: No keys found after filtering. 4.516:FAILURE DNSKEY signature did not validate. 4.516:FINAL_FAILURE FAILURE Based on the key tags and the truncated keys I think these keys are for fakessh.eu and if so there isn't a DLV record or a DS published for fakessh.eu. The only other thing the validator can check against is any installed trust-anchor. Mark ; DiG 9.6.0-APPLE-P2 fakessh.eu.dlv.isc.org dlv ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 48161 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ; DiG 9.6.0-APPLE-P2 fakessh.eu ds ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 63623 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 --=20 gpg --keyserver pgp.mit.edu --recv-key 092164A7 http://pgp.mit.edu:11371/pks/lookup?op=3Dgetsearch=3D0x092164A7 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users =20 =20 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users --=20 gpg --keyserver pgp.mit.edu --recv-key 092164A7 http://pgp.mit.edu:11371/pks/lookup?op=3Dgetsearch=3D0x092164A7 --=-PTfCUNzbM6WN0AFHL2g3 Content-Type: application/pgp-signature; name=signature.asc Content-Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?= -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQBNhoJZtXI/OwkhZKcRAujMAKCIR7D4r7o+rVlue7jdtUvzrIqAbwCcD9gt hw37QYLE5IuLPQXgUQI3qWc= =hDB7 -END PGP SIGNATURE- --=-PTfCUNzbM6WN0AFHL2g3-- --===8269614476746204563== Content-Type: text/plain; charset=us-ascii MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users --===8269614476746204563==-- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Not Exact error
In message f7c01ac623c2bd48a4b5a1e91ba1dc562456c33...@2008mbx.utmck.edu, Dav enport, Steve M writes: Can someone tell me the cause of the not exact error and how to troublesh= oot? 21-Mar-2011 11:01:24.931 xfer-in: error: transfer of '219.130.IN-ADDR.ARPA/= IN' from 130.219.31.5#53: failed while receiving responses: not exact After this message appears, a retry on the transfer runs error free. Thanks, Steve Not exact indicates that the nameserver found a change in a IXFR delta which it could not apply to the cleanly. It got asked to remove a record which didn't exist. It got asked to add a record that already existed. The TTL of the added record doesn't match that of the existing records of the RRset. If named detects a anomally like this it just re-transfers the zone. The following bug fix address one potential cause of these messages. The fix is currentl available in the following release: 9.6.3, 9.7.3 and 9.8.0. 3007. [bug] Named failed to preserve the case of domain names in rdata which is not compressible when writing master files. [RT #22863] -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Reverse dns issue
In message 4d8a0386.3080...@laas.fr, Olivier Destras writes: Hi, I'm using a software which uses bind and I'm experiencing a problem with the reverse dns function of bind. I only have private adresses on my network but the nodes also have dns names. There is a server on this network, which is also a name server, that has internet through a gateway. When my nodes are doing a dns query to the server, eveything is ok and they get their corresponding (private) IP address. The problem occurs when a node is sending a reverse dns query to the server. The server should return the name that matches the IP address but instead I have this error in the bind log 21-Mar-2011 14:53:44.389 security: warning: client 10.100.2.129#61940: view internal: RFC 1918 response from Internet for 5.2.100.10.in- addr.arpa In this case 10.100.2.5 (or 5.2.100.10) is the server itself so it should able to get his own name Only if you have configured the reverse zone. You need to configure a zone with a 5.2.100.10.in-addr.arpa. PTR name. record. e.g. 10.in-addr.arpa. 5.2.100 PTR name. or 100.10.in-addr.arpa. 5.2 PTR name. or 2.100.10.in-addr.arpa. 5 PTR name. or 5.2.100.10.in-addr.arpa. @ PTR name. This response from Internet seems weird to me because it should not ask an internet name server since it is private address. I checked with tcpdump and I didn't see any dns query going out of the server so it's not doing recursive lookups Did you clear the cache before checking? Anyone can help with this? Does bind have a special option for private addresses? No. Named knows what the public servers for 10.in-addr.arpa return in the SOA record and warns if it see those values. 10.in-addr.arpa.10800 IN SOA prisoner.iana.org. hostmaster.root-servers.org. 2002040800 1800 900 604800 604800 I've seen that there is a reverse folder in /etc/namedb with files names like this 10.0.252.db, are these files used for the reverse dns resolution? I tried to add a file for the subnetwork I use (10.100.2) but this didn't change anything Here is a tcpdump of the communication between the node and the server showing the failing query 10:42:35.494523 IP 10.100.2.129.60331 boss.vlan100.domain: 42377+ PTR? 5.2.100.10.in-addr.arpa. (41) 10:42:35.494691 IP boss.vlan100.domain 10.100.2.129.60331: 42377 NXDomain 0/1/0 (118) 10:42:35.495019 IP 10.100.2.129.54934 boss.vlan100.domain: 42378+ A? UNKNOWN.vlan100. (33) 10:42:35.495090 IP boss.vlan100.domain 10.100.2.129.54934: 42378 NXDomain* 0/1/0 (86) 10:42:35.495416 IP 10.100.2.129.64666 boss.vlan100.domain: 42379+ A? UNKNOWN. (25) 10:42:35.495469 IP boss.vlan100.domain 10.100.2.129.64666: 42379 NXDomain 0/1/0 (100) Thanks in advance ___ 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 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: rndc-key has expired
In message 1300893881.12273.67.camel@localhost.localdomain, fakessh @ write
s:
I use and bind rndc and dlv isc for dnssec=20
my zone config like this
zone renelacroute.fr {
type master;
file /var/named/renelacroute.fr.hosts;
auto-dnssec maintain;
update-policy local;
key-directory /var/named/keys/;
allow-transfer { 213.251.*.*;87.98.*.*; 195.234.*.*;94.23.*.\
*; 193.223.*.*; };
};
and my log dnssec it is
23-Mar-2011 16:18:17.701 dnssec: debug 2: tsig key 'rndc-key': signature
has expired
23-Mar-2011 16:18:17.701 dnssec: debug 2: tsig key 'rndc-key': signature
has expired
23-Mar-2011 16:18:18.244 dnssec: debug 2: tsig key 'rndc-key': signature
has expired
I can not use the script to validate the answers (for dnssec ) I isc
RNDC, TSIG and DNSSEC are *different* things.
TSIG is a transaction signature and by default it is valid for 5
minutes (tsig.fudge) from when it is computed. TSIG can be used
on zone transfers and to secure individual DNS transactions. The
format of TSIG log messages is tsig key '%s': %s and tsig key
'%s' (%s): %s. TSIG uses HMAC with private keys or it can use
public key cyptograhy similar to DNSSEC.
The DNS server and client being out of time sync can generate the
above messages. A slow TSIG signed zone transfer can also generate
the messages above even when the server and client are in sync if
it takes more than 5 minutes to send the signed messages in the
axfr/ixfr stream to the client.
RNDC, uses HMAC (private keys). It shares hmac keys with TSIG but
passes the expiry values differently. The format of its log messages
is invalid command from %s: %s
The above messages are not rndc related.
DNSSEC uses RRSIGs and they are valid for 30 days by default. DNSSEC
secures records in the transaction, not the transaction itself. You
have a secure transaction if all the components of the transaction are
secure and otherwise sensible.
The above messages are not DNSSEC related. The message below are
DNSSEC related.
Mark
SUCCESS 94.23.59.30 answered DNSKEY query with rcode NOERROR
5.814:SUCCESS 87.98.164.164 answered DNSKEY query with rcode NOERROR
5.814:SUCCESS 87.98.186.232 answered DNSKEY query with rcode NOERROR
5.814:INFO Total answers: 3
5.815:DEBUG COMPARE: Comparing results from 94.23.59.30 to 87.98.164.164
5.815:DEBUG COMPARE: Comparing results from 94.23.59.30 to 87.98.186.232
5.816:SUCCESS All DNSKEY responses are identical.
5.822:DEBUG VERIFY-DNSKEY: Checking tag=3D62721 flags=3D256 alg=3DRSASHA1
AwEAAb20...UzDMzFplHk=3D
5.822:DEBUG VERIFY-DNSKEY: Ignoring key.
5.822:DEBUG VERIFY-DNSKEY: Checking tag=3D48793 flags=3D257 alg=3DRSASHA1
AwEAAbj7...WFfCkn7o38=3D
5.822:DEBUG VERIFY-DNSKEY: Ignoring key.
5.822:INFO VERIFY-DNSKEY: 2 DNSKEYs found.
5.822:INFO VERIFY-DNSKEY: 0 keys found after filtering.
5.822:DEBUG VERIFY-DNSKEY: Using keys:
5.822:DEBUG VERIFY-DNSKEY: To verify rrset type DNSKEY
5.822:FAILURE VERIFY-DNSKEY: No keys found after filtering.
5.822:FAILURE DNSKEY signature did not validate.
5.822:FINAL_FAILURE FAILURE
Le mercredi 23 mars 2011 =C3=A0 09:29 +0100, Eivind Olsen a =C3=A9crit :
I edit the file named.conf
modification
update-policy {
grant * self * A TXT;
};
to update-policy local;
it seems more logical.
but I'm still stuck on the validation of isc dlv. the script tells me
lost keys
=20
Which script? What exactly does it say?
=20
I'm guessing you might have enabled dynamic updates in a DNSSEC signed
zone, without BIND having access to the private keys needed to sign, but
that's a wild guess really.
=20
Regards
Eivind Olsen
=20
=20
--=20
gpg --keyserver pgp.mit.edu --recv-key 092164A7
http://pgp.mit.edu:11371/pks/lookup?op=3Dgetsearch=3D0x092164A7
--=-nHmVHAZDpObhKURw8YiG
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: Ceci est une partie de message
=?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)
iD8DBQBNihC5tXI/OwkhZKcRAq2dAJ0SsEztSh/rgrKCYyo3JerXzjsOxgCggvQv
5jISvLMReyxov6dURql1lw0=
=e9RP
-END PGP SIGNATURE-
--=-nHmVHAZDpObhKURw8YiG--
--===8954482665668778810==
Content-Type: text/plain; charset=us-ascii
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
--===8954482665668778810==--
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Q on clients-per-query, max-clients-per-query
In message 60834.75625...@web121403.mail.ne1.yahoo.com, Fr34k writes: Hello, # The ARM says: # clients-per-query, max-clients-per-query These set the initial value (minimum) and maximum number of recursive simultaneous clients for any given query (qname,qtype,qclass) that the serv er will accept before dropping additional clients. named will attempt to self tu ne this value and changes will be logged. The default values are 10 and 100. If clients-per-query is set to zero, then there is no limit on the number of clients per query and no queries will be dropped. If max-clients-per-query i s set to zero, then there is no upper bound other than imposed by recursive-clients. # Consider that I have: # clients-per-query 10 ; max-clients-per-query 20 ; # What I think this means in hypothetical situations: # 1. If I have 100 customer Windows machines requesting A record(s) for non-responsive-domain.com, then my caching server will only recurs the first 20 of such requests and drop the other 80. Is this correct, or what is the like ly process? 2. If I have 100 customer Windows machines requesting A record(s) for very-slow-to-respond.com, then my caching server will only recurs the first 20 of such requests and drop the other 80. Is this correct, or what is the like ly process? Let's say the name servers authoritative for this domain finally respond, the n my bind server will respond to the 20 queries. Is this correct, or what is the likely process? Now that I have the A record for www.very-slow-to-respond.com in cache (say T TL is 24h) and it is likely that the 80 unsatisfied customer Windows machines wi ll make another query attempt and, because I have this cached, finally get a response. Is this correct, or what is the likely process? It won't hurt my feeling if someone rather provide a better example that may demonstrate how these settings work. You have a empty cache. You get a query for google.com. You send a query to the root servers for google.com. Another query for google.com comes in. You add it to the existing query for google.com. You get the answer back from the root servers. You ask the com servers for google.com. You get another 3 query for google.com, you add these to the original query. You get a response from the com servers. You ask the google.com servers for google.com. You get more queries for google.com. You get a answer back from the google.com servers and you send the answers back to all the clients that asked you for google.com. Future queries for google.com will be answered from the cache until the record expires. Now if more than 10 clients ask you for google.com while this is happening you will just drop the new clients (they should retry). Named will remember that it dropped clients and as it got a answer it will increase the number of clients that it serve for the next query. It's a little more complicted than this but this will do for this explaination. This lets named adjust to the normal query rate and how far it is from the usual nameservers it talks to round trip wise. This normally take less than a second. Now lets say the servers for a zone are unreachable. Named will only queue up 10 clients before it starts dropping them. This stops the recursive client slots all being taken on queries talking to these servers. Similar a flash crowd of queries for the same name will be mostly dropped until the answer is received. Mark Thank you. ___ 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 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Q on clients-per-query, max-clients-per-query
In message 688460.82562...@web121414.mail.ne1.yahoo.com, Fr34k writes: - Original Message From: Mark Andrews To: Fr34k Cc: Bindlist Sent: Wed, March 23, 2011 9:04:00 PM Subject: Re: Q on clients-per-query, max-clients-per-query In message , Fr34k writes: Hello, # The ARM says: # clients-per-query, max-clients-per-query These set the initial value (minimum) and maximum number of recursive simultaneous clients for any given query (qname,qtype,qclass) that the serv er will accept before dropping additional clients. named will attempt to se lf tu ne this value and changes will be logged. The default values are 10 and 10 0. If clients-per-query is set to zero, then there is no limit on the numbe r of clients per query and no queries will be dropped. If max-clients-per-qu ery i s set to zero, then there is no upper bound other than imposed by recursive-clients. # Consider that I have: # clients-per-query 10 ; max-clients-per-query 20 ; # What I think this means in hypothetical situations: # 1. If I have 100 customer Windows machines requesting A record(s) for non-responsive-domain.com, then my caching server will only recurs the f irst 20 of such requests and drop the other 80. Is this correct, or what is the like ly process? 2. If I have 100 customer Windows machines requesting A record(s) for very-slow-to-respond.com, then my caching server will only recurs the f irst 20 of such requests and drop the other 80. Is this correct, or what is the like ly process? Let's say the name servers authoritative for this domain finally respond , the n my bind server will respond to the 20 queries. Is this correct, or what is the likely process? Now that I have the A record for www.very-slow-to-respond.com in cache ( say T TL is 24h) and it is likely that the 80 unsatisfied customer Windows machin es wi ll make another query attempt and, because I have this cached, finally get a response. Is this correct, or what is the likely process? It won't hurt my feeling if someone rather provide a better example that may demonstrate how these settings work. You have a empty cache. You get a query for google.com. You send a query to the root servers for google.com. Another query for google.com comes in. You add it to the existing query for google.com. You get the answer back from the root servers. You ask the com servers for google.com. You get another 3 query for google.com, you add these to the original query. You get a response from the com servers. You ask the google.com servers for google.com. You get more queries for google.com. You get a answer back from the google.com servers and you send the answers back to all the clients that asked you for google.com. Future queries for google.com will be answered from the cache until the record expires. Now if more than 10 clients ask you for google.com while this is happening you will just drop the new clients (they should retry). Named will remember that it dropped clients and as it got a answer it will increase the number of clients that it serve for the next query. It's a little more complicted than this but this will do for this explaination. This lets named adjust to the normal query rate and how far it is from the usual nameservers it talks to round trip wise. This normally take less than a second. Now lets say the servers for a zone are unreachable. Named will only queue up 10 clients before it starts dropping them. This stops the recursive client slots all being taken on queries talking to these servers. Similar a flash crowd of queries for the same name will be mostly dropped until the answer is received. So, does BIND behave the same whether it is a single PC making 100 queries fo r the same record compared to 555 PCs making queries for the same record? That is, how does BIND treat clients-per-query, max-clients-per-query differently based upon the query requesters' IP address(es)? (I want to assume I know the answer, but I have an interesting network event and I want to be able to understand/communicate the snoop logs we captured) I'm using 9.7.2-P2, if version is significant. Thank you. Named uses the source address, source port and query id to find duplicate queries. Duplicate queries are dropped before the clients-per-query code. A client is not a machine. It is a process/task on a machine. The code to find the existing query can fail to find it in the version of named you are running. This is fixed in 9.6.3, 9.7.3 and 9.8.0. 3009. [bug] clients-per-query code didn't work as expected with particular query patterns. [RT #22972
Re: problem for validate the script dnssec to isc dlv
In message 1300993213.12273.96.camel@localhost.localdomain, fakessh @ write s: hi bind //guru/ hi isc guru hi mark andrews hi michel graff There are no DLV records for fakessh.eu. See below. There are no DS records for fakessh.eu. See below. Two of the nameservers for your zone are not DNSSEC enabled. They do NOT return RRSIG records when asked for the DNSKEY records with DO=1. See below. You need to address these issues. Mark % dig fakessh.eu.dlv.isc.org dlv ; DiG 9.6.0-APPLE-P2 fakessh.eu.dlv.isc.org dlv ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 21760 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;fakessh.eu.dlv.isc.org.IN DLV ;; AUTHORITY SECTION: dlv.isc.org.2793IN SOA ns-int.isc.org. hostmaster.isc.org. 2011032404 7200 3600 2419200 3600 ;; Query time: 3 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Fri Mar 25 08:10:56 2011 ;; MSG SIZE rcvd: 94 % dig ds fakessh.eu ; DiG 9.6.0-APPLE-P2 ds fakessh.eu ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 20600 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;fakessh.eu.IN DS ;; AUTHORITY SECTION: eu. 600 IN SOA a.nic.eu. tech.eurid.eu. 1003425849 3600 1800 360 600 ;; Query time: 930 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Fri Mar 25 08:13:44 2011 ;; MSG SIZE rcvd: 81 % dig +dnssec dnskey fakessh.eu @ns0.xname.org ; DiG 9.6.0-APPLE-P2 +dnssec dnskey fakessh.eu @ns0.xname.org ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 11804 ;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 5, ADDITIONAL: 6 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;fakessh.eu.IN DNSKEY ;; ANSWER SECTION: fakessh.eu. 38400 IN DNSKEY 256 3 5 AwEAAeFYV9JtqoHqpU8vpl+wMFOQjt77N5XgUcove5Apmjwqsx/awcbN Q2+H3hqeJ9f8NRSDUamSLFmvuUJTbDLDxpw9AlNjZNXQysxaQ//lNXKR P2nfrbqMvNnerzdPQ1eF2RqMf5XuOFv6+4UFz/rykszQcK6kH4qIWQ89 Ibk4eXc249MP31vUlgf3tiHyWyqQtD2JJpHY3HwDOYHhKR0Rilk= fakessh.eu. 38400 IN DNSKEY 257 3 5 AwEAAbj75OmR1A8gs1lda3OYTKaY+dy4jVBmflEk/c8g/JDw6UvAqWMz 9KtNIZvGt9E8JMSfaH6VZLY0mWFfCkn7o38= ;; AUTHORITY SECTION: fakessh.eu. 38400 IN NS r13151.ovh.net. fakessh.eu. 38400 IN NS ns0.xname.org. fakessh.eu. 38400 IN NS ns1.xname.org. fakessh.eu. 38400 IN NS ns1.novacrea.fr. fakessh.eu. 38400 IN NS ns2.xname.org. ;; ADDITIONAL SECTION: ns0.xname.org. 600 IN A 195.234.42.1 ns1.xname.org. 600 IN A 87.98.164.164 ns1.novacrea.fr.55352 IN A 94.23.59.30 ns2.xname.org. 600 IN A 88.191.64.64 ns2.xname.org. 600 IN 2a01:e0b:1:64:240:63ff:fee8:6155 ;; Query time: 391 msec ;; SERVER: 195.234.42.1#53(195.234.42.1) ;; WHEN: Fri Mar 25 08:19:34 2011 ;; MSG SIZE rcvd: 515 % despite my efforts to validate isc dlv. I'm always at the same point I can not validate the keys. error below the script isc SUCCESS 94.23.59.30 answered DNSKEY query with rcode NOERROR 3.345:SUCCESS 87.98.186.232 answered DNSKEY query with rcode NOERROR 3.345:SUCCESS 87.98.164.164 answered DNSKEY query with rcode NOERROR 3.345:INFO Total answers: 3 3.346:DEBUG COMPARE: Comparing results from 94.23.59.30 to 87.98.186.232 3.347:DEBUG COMPARE: Comparing results from 94.23.59.30 to 87.98.164.164 3.347:SUCCESS All DNSKEY responses are identical. 3.353:DEBUG VERIFY-DNSKEY: Checking tag=3D41931 flags=3D256 alg=3DRSASHA1 AwEAAbjq...Na0iXShQfc=3D 3.353:DEBUG VERIFY-DNSKEY: Ignoring key. 3.353:DEBUG VERIFY-DNSKEY: Checking tag=3D27979 flags=3D257 alg=3DRSASHA1 AwEAAcNa...y1khCE+CdE=3D 3.353:DEBUG VERIFY-DNSKEY: Ignoring key. 3.353:INFO VERIFY-DNSKEY: 2 DNSKEYs found. 3.353:INFO VERIFY-DNSKEY: 0 keys found after filtering. 3.353:DEBUG VERIFY-DNSKEY: Using keys: 3.353:DEBUG VERIFY-DNSKEY: To verify rrset type DNSKEY 3.353:FAILURE VERIFY-DNSKEY: No keys found after filtering. 3.353:FAILURE DNSKEY signature did not validate. 3.353:FINAL_FAILURE FAILURE --=20 gpg --keyserver pgp.mit.edu --recv-key 092164A7 http://pgp.mit.edu:11371/pks/lookup?op=3Dgetsearch=3D0x092164A7 --=-z4QlW2bZGkH+0Mp+jCTf Content-Type: application/pgp-signature; name=signature.asc Content-Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?= -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQBNi5S9tXI/OwkhZKcRApwbAJ0U1bwNJxcqaQio8bGVIuAQkomMqgCfVbUn uZ2ojYfEyGYxmZu/F2xOJn8= =/8X8 -END PGP SIGNATURE
Re: problem for validate the script dnssec to isc dlv
In message 1301004136.12273.106.camel@localhost.localdomain, fakessh @ writes: Le vendredi 25 mars 2011 =C3=A0 08:24 +1100, Mark Andrews a =C3=A9crit : In message 1300993213.12273.96.camel@localhost.localdomain, fakessh @= write s: hi bind //guru/ hi isc guru hi mark andrews hi michel graff There are no DLV records for fakessh.eu. See below. There are no DS records for fakessh.eu. See below. necessarily because I can not validate the key through via isc dlv One of these is necessary. You have neither. Additionally the DS for fakessh.eu is the best long term solution as it will be used by more people. Mark Two of the nameservers for your zone are not DNSSEC enabled. They do NOT return RRSIG records when asked for the DNSKEY records with DO=1. See below. You need to address these issues. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: problem for validate the script dnssec to isc dlv
1.569:DEBUG RUN: Got activity for 9, from 2001:500:60::30 1.569:DEBUG RUN: Found answer from 2001:500:60::30 1.673:DEBUG RUN: Got activity for 8, from 199.6.1.30 1.673:DEBUG RUN: Found answer from 199.6.1.30 1.677:SUCCESS 83.246.72.252 answered DNSKEY query with rcode NOERROR 1.677:SUCCESS 2001:500:71::30 answered DNSKEY query with rcode NOERROR 1.677:SUCCESS 2001:500:60::30 answered DNSKEY query with rcode NOERROR 1.677:SUCCESS 2001:4F8:0:2::19 answered DNSKEY query with rcode NOERROR 1.677:SUCCESS 149.20.64.3 answered DNSKEY query with rcode NOERROR 1.677:SUCCESS 93.186.33.42 answered DNSKEY query with rcode NOERROR 1.677:SUCCESS 199.6.1.30 answered DNSKEY query with rcode NOERROR 1.677:SUCCESS 2001:4B10:100:7::53 answered DNSKEY query with rcode NOERROR 1.678:SUCCESS 199.6.0.30 answered DNSKEY query with rcode NOERROR 1.678:INFO Total answers: 9 1.679:DEBUG COMPARE: Comparing results from 83.246.72.252 to 2001:500:71::30 1.679:DEBUG COMPARE: Comparing results from 83.246.72.252 to 2001:500:60::30 1.680:DEBUG COMPARE: Comparing results from 83.246.72.252 to 2001:4F8:0:2::19 1.680:DEBUG COMPARE: Comparing results from 83.246.72.252 to 149.20.64.3 1.681:DEBUG COMPARE: Comparing results from 83.246.72.252 to 93.186.33.42 1.681:DEBUG COMPARE: Comparing results from 83.246.72.252 to 199.6.1.30 1.682:DEBUG COMPARE: Comparing results from 83.246.72.252 to 2001:4B10:100:7::53 1.682:DEBUG COMPARE: Comparing results from 83.246.72.252 to 199.6.0.30 1.682:SUCCESS All DNSKEY responses are identical. 1.690:DEBUG VERIFY-DNSKEY: Checking tag=14518 flags=257 alg=RSASHA1 AwEAAail...w9T7jCEO3U= 1.690:DEBUG VERIFY-DNSKEY: Accepted key. 1.690:DEBUG VERIFY-DNSKEY: Checking tag=64476 flags=256 alg=RSASHA1 AwEAAcVl...QbW/yEAnhON 1.691:DEBUG VERIFY-DNSKEY: Ignoring key. 1.691:INFO VERIFY-DNSKEY: 2 DNSKEYs found. 1.691:INFO VERIFY-DNSKEY: 1 keys found after filtering. 1.691:DEBUG VERIFY-DNSKEY: Using keys: 1.691:DEBUG VERIFY-DNSKEY: tag=14518 flags=257 alg=RSASHA1 AwEAAail...w9T7jCEO3U= 1.691:DEBUG VERIFY-DNSKEY: To verify rrset type DNSKEY 1.695:SUCCESS DNSKEY signatures validated. 1.696:SUCCESS VALIDATED_SEP_KEY: andrews.wattle.id.au. 3600 IN DNSKEY 257 3 RSASHA1 ( AwEAAailzXCUvRIfjCiZ548gPx+y+/W5Nab2TOMdsQweYFfJw00XRdIGH2OW6S+rLVqlx5Di0fyS44MR/vHizHCp+9MtzSKiJvly6EOYo9ckAmtYrwpdQhERAzkAF35EsF0JJzn6xZThIPYsyw+17gc+lf75GQ0ZPiJgKigTk1/gdOlCN497tzo3Fu7T8u4ymwf49Gl3NpMAvGCNP7UK2HSiVy7+CNc7X5VkSEqvq5/ZNQHj2uTfrqeEAk1+4llo6xa+n+s23lhOzXymWMyAIGr9SZ2fqj7mYceQvAGDSO/VkmY/WrARqEbUJAqroJV8f8tVajQlS6FomY5d2w9T7jCEO3U= ) ; key_tag=14518 1.696:INFO Name servers which responded: 83.246.72.252, 2001:500:71::30, 2001:500:60::30, 2001:4F8:0:2::19, 149.20.64.3, 93.186.33.42, 199.6.1.30, 2001:4B10:100:7::53, 199.6.0.30 1.696:FINAL_SUCCESS Success. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: problem for validate the script dnssec to isc dlv
Mark Andrews writes: In message 1301008426.12273.115.camel@localhost.localdomain, fakessh @ wr ites: it is 6 months since I used no worries dlv What keys do you have recorded with dlv.isc.org? Do they match what you currently have in the zone? You did not answer these questions. Please answer these questions. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: problem for validate the script dnssec to isc dlv
In message 1301241108.12273.192.camel@localhost.localdomain, fakessh @ writ es: i use the key BEPHMu/5onzrEE7z1egmhg/WPO0+juoZrW3euWEn4MxDCE 1+lLy2brhQv5rN32RKtMzX6Mj70jdzeND4XknW58dnJNPCxn8+ jAGl2FZLK8t+1uq4W+nnA3qO2+DL+k6BD4mewMLbIYFwe0PG73 Te9fZ2kJb56dhgMde5ymX4BI/oQ+cAK50/xvJv00Frf8kw6ucM TwFlgPe+jnGxPPEmHAte/URkY62ZfkLoBAADLHQ9IrS2tryAe7 mbBZVcOwIeU/Rw/mRx/vwwMCTgNboMQKtUdvNXDrYJDSHZws3x iRXF1Rf+al9UmZfSav/4NWLKjHzpT59k/VStTDN0YUuWrBNh and the other key include in the tarvall of bind Submit the SEP key for fakessh.eu. fakessh.eu. 38356 IN DNSKEY 257 3 5 AwEAAaXxSyYC5WHJdozSpEX5foltzSpNYJZb78zJldfgHF8zseINQNQj xQp9SdxsM81n6xw68zuJtd0I2grxexvQ0N4SdwM70tifbZD0VTBr8vgr rMOwfP2tCTzI/3VqHpFl+JZEcbcJqX4HcYh+fH9s+ZwHgybJ9FeSzYmu CakqAfHn -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: problem for validate the script dnssec to isc dlv
In message 1301245765.12273.198.camel@localhost.localdomain, fakessh @ writes: in insurance I googled no result how to do this ... https://dlv.isc.org Click on Login. Enter you user name and password. You should see fakessh.eu in the table of zones. Click on (add) under Keys for fakessh.eu. Cut and paste the entire record from below into the field under Add Record. To get rid of a old record. After logging in click on (details) for the zone you want to remove the record from. Find the record you want to delete and click on (details). In status click on (delete record). Mark nb : i reajust my blog immediately Le lundi 28 mars 2011 =C3=A0 03:43 +1100, Mark Andrews a =C3=A9crit : In message 1301241108.12273.192.camel@localhost.localdomain, fakessh @= writ es: i use the key BEPHMu/5onzrEE7z1egmhg/WPO0+juoZrW3euWEn4MxDCE 1+lLy2brhQv5rN32RKtMzX6Mj70jdzeND4XknW58dnJNPCxn8+ jAGl2FZLK8t+1uq4W+nnA3qO2+DL+k6BD4mewMLbIYFwe0PG73 Te9fZ2kJb56dhgMde5ymX4BI/oQ+cAK50/xvJv00Frf8kw6ucM TwFlgPe+jnGxPPEmHAte/URkY62ZfkLoBAADLHQ9IrS2tryAe7 mbBZVcOwIeU/Rw/mRx/vwwMCTgNboMQKtUdvNXDrYJDSHZws3x iRXF1Rf+al9UmZfSav/4NWLKjHzpT59k/VStTDN0YUuWrBNh =20 and the other key include in the tarvall of bind =20 Submit the SEP key for fakessh.eu. =20 fakessh.eu. 38356 IN DNSKEY 257 3 5 AwEAAaXxSyYC5WHJdozSpEX5foltzSpNYJZb= 78zJldfgHF8zseINQNQj xQp9SdxsM81n6xw68zuJtd0I2grxexvQ0N4SdwM70tifbZD0VTBr8v= gr rMOwfP2tCTzI/3VqHpFl+JZEcbcJqX4HcYh+fH9s+ZwHgybJ9FeSzYmu CakqAfHn =20 =20 --=20 gpg --keyserver pgp.mit.edu --recv-key 092164A7 http://pgp.mit.edu:11371/pks/lookup?op=3Dgetsearch=3D0x092164A7 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: is notify message going with UDP or TCP?
In message AANLkTin32s_ZrrzsznV=HhqAc02Rv73p=-Z6eTcQU=e...@mail.gmail.com, terr y writes: BIND master sends the notify message with TCP or UDP protocal? UDP. Thanks. ___ 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 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Trouble loading a zone file after updating BIND
In message Pine.WNT.4.64.1103302249090.2864@diggins-PC, Mike Diggins writes: On the master name server, I'm upgrading BIND from an older version, 9.2.1, to 9.7. However, when I attempt to load this zone Domain.CA, it gives me an error: 9.7 catches more common configuration errors. Remember nameservers can't catch all configuration errors. Just because a zone loads doesn't mean that it will work. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9 And Short Name resolution Problem
In message 4d956ac7.2010...@data.pl, Torinthiel writes:
On 03/31/11 20:58, Barry Finkel wrote:
On 03/31/11 13:17, bind-users-requ...@lists.isc.org wrote:
Hello,
I get the following messages on the BIND server when I do a short name=
nslookup from a client:
Mar 31 14:08:04 jedi named[1299]: [ID 873579 daemon.info] network
unreachable resolving 'C.ROOT-SERVERS.NET//IN':
2001:500:1::803f:235#53
Mar 31 14:08:05 jedi named[1299]: [ID 873579 daemon.info] network
unreachable resolving 'I.ROOT-SERVERS.NET//IN':
2001:500:1::803f:235#53
Mar 31 14:08:07 jedi named[1299]: [ID 873579 daemon.info] network
unreachable resolving 'B.ROOT-SERVERS.NET//IN': 2001:500:2f::f#53
Mar 31 14:08:07 jedi named[1299]: [ID 873579 daemon.info] network
unreachable resolving 'L.ROOT-SERVERS.NET//IN': 2001:500:2f::f#53
The config files are below, we are running BIND 9 on Solaris 10. We
currently have 2 domain names configured and on IP address on the BIND=
server itself. Any ideas from the gurus??
Thanks
=20
You do not have IPv6 connectivity from the DNS server to
{C,I,B,L}.root-servers.net.
And is it possible to make BIND stop trying to use IPv6 at all? I'm in a
similar situation, I know I have connection issues and I simply want
bind to either not use IPv6 or at least prefer IPv4.
liste-on-v6 {none;} in named.conf does not help, and I'm not much
surprised, as it's about listening and not querying.
Torinthiel
named -4
If you need to be more selective see server.
e.g.
To just use 6to4 homed server.
server ::/0 { bogus yes; };
server 2002::/16 { bogus no; };
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.7 behavior - lack of response causes
What do you have lame-ttl set to? In message 361220.19486...@web121407.mail.ne1.yahoo.com, Fr34k writes: Hello, Given: BIND 9.7.2-P2 on Solaris 10. For about an hour, I had a network event where a caching DNS server could not get recursive queries back from authoritative DNS servers on the Internet. Obviously, this is a problem. Moreover, the authority for our most popular hostnames have set very low TTLs (less than a minute), so nothing in cache for the server to call upon during this hour long event. Yuck. A snoop of port 53 traffic at the time shows client PCs requested hostname resolution -- as they would normally do. Now, for the interesting part. From the same snoop of traffic, the caching DNS server did not send ANY resp onse back to these PC clients for these low TTL popular hostnames. Keep in mind that I did snoop until *after* the event started. So, it may be the case that some BIND mechanism was behaving appropriate for queries which it could not act upon. I can appreciate that BIND makes decisi ons with network performance in mind. In my attempts to understand negative caching, Sections 7.1 and 7.2 of RFC 23 08 list Server Failure and Dead / Unreachable Server as (OPTIONAL) utilities. Bind 9.7 ARM says that the server stores negative answers for (default) 3 hours; however, I'm not sure what the expected BIND behavior is. Would some mechanism, such has max-ncache-ttl or clients-per-query, be responsible for this lack of return traffic? Anyone have ideas to share? Thank you. ___ 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 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: 9.8.0 in 2008 R2 x64 server
In message alpine.bsf.2.00.1104052216180.2...@bikeshed.isc.org, Dan Mahoney w rites: On Tue, 5 Apr 2011, Jukka Pakkanen wrote: I'm moving one of our DNS servers (Win 2003 R2, v9.7.0) to a new 2008 R2 x6 4 server. After installing v9.8.0 I copied the /etc directory subdirectories, the named user has full rights in relevant directories and log on as a service rights... still I get the following error in eventviewer when trying to sta rt the service: none:0: open: C:\Windows\system32\dns\etc\named.conf: file not found Any ideas? The named.conf file IS there, and the directories/datafiles are identical to our old, working server. Tested with administator as the us er as well, same problem. Windows Vista and Windows 2008 maps system32 filenames to a different location that I can't remember off the top of my head. I would uninstall named and then re-install it in C:\Program Files\ISC\BIND9 or similar to avoid the mapping. The location of the configuration files are stored in the registry so everything should work if you do this. Start a command shell as that user and try to more the file? -Dan ___ 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 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Change Query Type on nslookup
In message 4d9d502d.7080...@data.pl, Torinthiel writes: On 04/07/11 06:42, mee thun wrote: Good Morning.. =20 I am new member in this mailing list. I need help to change the query type in the nslookup command. The default nslookup using A, but I use ipv6 so the query type must use= . I don't know how to change the default nslookup from A to permanently? first, this is a bind list, and nslookup is not a bind tool. Consider using dig, which is much better in this case. nslookup is a BIND tool, we just tried hard to deprecate it. And, IIRC, when you run nslookup you can put set type= yourquery.com and that should give the effect you want I have no idea how to change the default query type for any of the tools.= Torinthiel --enigF96CA10530F411769FF2D20E Content-Type: application/pgp-signature; name=signature.asc Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=signature.asc -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2dUDQACgkQfOvN3AkGos4kKQCfXmxr8PknsEXyCswBqqdehAE2 orgAnjxP66xpZGxTQFKESsxSPMFCLxxp =T21l -END PGP SIGNATURE- --enigF96CA10530F411769FF2D20E-- --===7001123361952416593== Content-Type: text/plain; charset=us-ascii MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users --===7001123361952416593==-- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Anyway to disable dns_zone_nscheck in 9.8.0?
In message BANLkTi=h1onrtxdtdfmpgkz7slrglyt...@mail.gmail.com, Rodney Hives w rites: The dns_zone_nscheck is a real pain for domains that do not have valid A records (for their NS records). Is there anyway to disable this check? I started noticing this problem in 9.7xs. But at this point I just want to remove it as it is causing many problems for previous configured name servers. There seems to value in the master.h for DNS_MASTER_CHECKNS which is similar to the other checks (DNS_MASTER_CHECKMX, DNS_MASTER_CHECKMXFAIL, etc.) that you can turn off in the options of named.conf. But I do not see any option to remove the dns_zone_nscheck. Has anyone removed this function safely? If so, how? Thank you! -Rodney Hives Please explain the operating conditions under which when you think this is a sensible thing to do? A nameserver without address records is pointless. A nameserver pointing to a CNAME/DNAME causes resolution problems. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Anyway to disable dns_zone_nscheck in 9.8.0?
In message banlktimic+ndbnj_rovnhqwzas130bv...@mail.gmail.com, Rodney Hives w rites: On Fri, Apr 8, 2011 at 1:49 AM, Mark Andrews ma...@isc.org wrote: Please explain the operating conditions under which when you think this is a sensible thing to do? A nameserver without address records is pointless. A nameserver pointing to a CNAME/DNAME causes resolution problems. Here is an example that works in BIND 9.6x: $ORIGIN . $TTL 86400 ; 1 day mydomain.com.au IN SOA ns0.mydomain.com.au. admin.mydomain.com.au. ( 2011010104 ; serial 43200 ; refresh (12 hours) 7200; retry (2 hours) 1209600 ; expire (2 weeks) 1800; minimum (30 minutes) ) $TTL 1800 ; 30 minutes NS ns0.mydomain.com.au. NS ns1.mydomain.com.au. NS ns2.mydomain.com.au. A 1.1.1.1 MX 10 mail.mydomain.com.au. $ORIGIN mydomain.com.au. ftp A 1.1.1.1 mailA 2.2.2.2 pop CNAME mail smtpCNAME mail ssh A 1.1.1.1 www CNAME mydomain.com.au. Is this domain 100% valid?... no... but it still works. The A records for the name servers are actually still resolving since the regsitrar will return them in glue. Do you realise how increadibly fragile that configuration is? The moment the recursive server asks for the addresses of the nameservers it will fall over. Yes the recursive nameserver can get into a state where it will make that request as part of resolving some other name in the zone. You don't need a external query for the nameserver names. But understandably... this domain is not 100% valid. But to force the domain offline is just preventing many shared hosting environments to move to newer versions of BIND (or switch off of BIND since they do not understand the problem). Nobody is preventing you fixing the zones. Give a warning... that is fine... But to prevent the domain from loading is just too harsh and an immediate drastic measure during an upgrade. It would be nice if it was a configuration option just like all of the other checks. People ignore warnings. We have 2 decades of experience of people ignoring warnings. The code was put in because we were sick and tired of having to contact people with misconfigured zones like this that were causing resolution failures. We made it a warning initially. It was made a fatal error a couple of releases later. The version you upgraded from warned about this. BIND 9.4 warned about this. named-checkzone from BIND 9.4 produces the following on your zone. It calls exactly the same code named uses. zone mydomain.com.au/IN: NS 'ns0.mydomain.com.au' has no address records (A or ) zone mydomain.com.au/IN: NS 'ns1.mydomain.com.au' has no address records (A or ) zone mydomain.com.au/IN: NS 'ns2.mydomain.com.au' has no address records (A or ) zone mydomain.com.au/IN: loaded serial 2011010104 OK Your logs would have been full of complaints. You could have run named-checkconf -z and seen all the errors before you started named. This same function seems also to be called in update.c.. also causing problems. I would just like this function to never be called but I have not been able to determine if it does other things necessary. It prevents the zone getting into a state where it won't load on a restart from this test. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.8.0 + openssl 1.0.0d + chroot == issues
In message 4dadfb29.6080...@dougbarton.us, Doug Barton writes: I have had 2 reports now of people using BIND 9.8.0 on FreeBSD compiled against openssl 1.0.0d not being able to chroot unless they copy $PREFIX/lib/engines/libgost.so into the chroot environment. Traditionally, copying libs into the chroot directory has not been necessary, so I'm curious. Building 9.8 against the default openssl in the FreeBSD base (0.9.8q) I have not experienced this problem. I haven't actually tried this with 1.0.0d myself yet, so I thought I'd ask about it here first before filing a bug report. Could this be a (previously unknown form of) user error? Or is it an actual BIND bug (or an openssl bug for that matter)? It's a matter of how OpenSSL is built. You can build openssl with gost as a dynamically loaded engine or you can build openssl with the engines already linked in. Gost, unlike the rest of the crypto, is implemented as a engine. Thanks, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ 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 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: the valid content of TXT RR
In message BANLkTik=rv4nh7noo5+rdegp6yet4nx...@mail.gmail.com, Doug writes: Hello, what characters can or can't be included in a TXT record for DNS? Thanks. Named supports 8 bit data using the same presentation encoding as domain names. e.g. 0x00 is \000, 0xff is \255 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC signing issues
In message 8D870AB38C30EC4C848A11A3F83D20D801733325E60C@exchange2007.mmicmanho
menet.local, Security Admin (NetSec) writes:
I am running BIND 9.4.2-P2 on OpenBSD v4.8
I have created the ZSK and KSK and added the keys to my zonefile mydomain.=
hosts using the cat command to append to the end of the host file.
When attempting to use the following command dnssec-signzone -N INCREMENT =
mydomain.hosts I get the following error:
dnssec-signzone: error: dns_master_load: mydomain.hosts:15: mydomain.com: n=
ot at top of zone
dnssec-signzone: failed loading zone from ' mydomain.hosts': not at top of =
zone
I own this domain and the DNS servers associated with them. Line 15 refere=
nced in the above error is an MX record within the host file. I am unsure h=
ow to debug this error. Any help would be appreciated.
Specify the zone name with -o mydomain.com. By default the zone matches
the file name.
--_000_8D870AB38C30EC4C848A11A3F83D20D801733325E60Cexchange200_
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
html xmlns:v=3Durn:schemas-microsoft-com:vml xmlns:o=3Durn:schemas-micr=
osoft-com:office:office xmlns:w=3Durn:schemas-microsoft-com:office:word =
xmlns:m=3Dhttp://schemas.microsoft.com/office/2004/12/omml; xmlns=3Dhttp:=
//www.w3.org/TR/REC-html40headmeta http-equiv=3DContent-Type content=
=3Dtext/html; charset=3Dus-asciimeta name=3DGenerator content=3DMicros=
oft Word 14 (filtered medium)style!--
/* Font Definitions */
@font-face
{font-family:Cambria Math;
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:Calibri,sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:Calibri,sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:Calibri,sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--/style!--[if gte mso 9]xml
o:shapedefaults v:ext=3Dedit spidmax=3D1026 /
/xml![endif]--!--[if gte mso 9]xml
o:shapelayout v:ext=3Dedit
o:idmap v:ext=3Dedit data=3D1 /
/o:shapelayout/xml![endif]--/headbody lang=3DEN-US link=3Dblue vli=
nk=3Dpurplediv class=3DWordSection1p class=3DMsoNormalI am running BIN=
D 9.4.2-P2 on OpenBSD v4.8o:p/o:p/pp class=3DMsoNormalo:pnbsp;/=
o:p/pp class=3DMsoNormalI have created the ZSK and KSK and added the k=
eys to my zonefile #8220;mydomain.hosts#8221;nbsp; using the #8220;cat=
#8221; command to append to the end of the host file.o:p/o:p/pp clas=
s=3DMsoNormalo:pnbsp;/o:p/pp class=3DMsoNormalWhen attempting to =
use the following command #8220;dnssec-signzone -N INCREMENT mydomain.host=
s#8221; I get the following error:o:p/o:p/pp class=3DMsoNormalo:p=
nbsp;/o:p/pp class=3DMsoNormalidnssec-signzone: error: dns_master=
_load: mydomain.hosts:15: mydomain.com: not at top of zoneo:p/o:p/i/=
pp class=3DMsoNormalidnssec-signzone: failed loading zone from ' mydom=
ain.hosts': not at top of zoneo:p/o:p/i/pp class=3DMsoNormalio=
:pnbsp;/o:p/i/pp class=3DMsoNormalI own this domain and the DNS s=
ervers associated with them.nbsp; Line 15 referenced in the above error is=
an MX record within the host file. I am unsure how to debug this error.nb=
sp; Any help would be appreciated.o:p/o:p/p/div/body/html=
--_000_8D870AB38C30EC4C848A11A3F83D20D801733325E60Cexchange200_--
--===5749675706925016482==
Content-Type: text/plain; charset=us-ascii
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
--===5749675706925016482==--
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
