Re: id.server on 9.18.24
Solved by adding 'server-id' to named.conf.options. Thank you Petr Špaček for the suggestion. Op 14/02/2024 om 10:23 schreef Marco Davids (SIDN): I have upgraded two servers to 9.18.24 and the funny thing is that on one server id.servers works well: ;; ANSWER SECTION: id.server. 0 CH TXT "one" And on the other it does not: ;; AUTHORITY SECTION: id.server. 86400 CH SOA id.server. hostmaster.id.server. 0 28800 7200 604800 86400 -- Marco OpenPGP_signature.asc Description: OpenPGP digital signature -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
id.server on 9.18.24
I have upgraded two servers to 9.18.24 and the funny thing is that on one server id.servers works well: ;; ANSWER SECTION: id.server. 0 CH TXT "one" And on the other it does not: ;; AUTHORITY SECTION: id.server. 86400 CH SOA id.server. hostmaster.id.server. 0 28800 7200 604800 86400 Also, the NSID-output is missing. I'm not sure where to look for clues as to what is actually happening, hence I'm dropping it here to check if it is just me. ANY queries give: ;; ANSWER SECTION: id.server. 0 CH TXT "xsauth" id.server. 86400 CH SOA id.server. hostmaster.id.server. 0 28800 7200 604800 86400 id.server. 0 CH NS id.server. and ;; ANSWER SECTION: id.server. 86400 CH SOA id.server. hostmaster.id.server. 0 28800 7200 604800 86400 id.server. 0 CH NS id.server. Other queries, like authors.bind, hostname.bind, version.bind, seem to work fine. -- Marco Davids Research Engineer SIDN | Meander 501 | 6825 MD | Postbus 5022 | 6802 EA | ARNHEM T +31 (0)26 352 55 00 | www.sidnlabs.nl | Twitter: @marcodavids https://mastodon.social/@marcodavids | Matrix: @marco:sidnlabs.nl Nostr: 11ed01ff277d94705c2931867b8d900d8bacce6f27aaf7440ce98bb50e02fb34 OpenPGP_signature.asc Description: OpenPGP digital signature -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
feature request for improving named-compilezone
Hi, How hard would it be to let named-compilezone keep any remarks that are present in the source file? Because now it strips them and that is problematic. -- Marco OpenPGP_signature.asc Description: OpenPGP digital signature -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Intent and implementation of dig's +crypto option
Hi Anand, Op 22-09-2023 om 14:46 schreef Anand Buddhdev: Do you think that dig should be adjusted to suppress cryptographic material from other records such as TLSA, SSHFP, CDNSKEY, CDS, etc, and the man page updated to reflect this? Great discussion! I don't have any strong opinions just yet. But when you wrote this: > When I query using dig, and use the combination "+nocrypto +dnssec" It reminded me that that there is such thing as a .digrc file, that perhaps not all of the readers are familiar with. Mine has this content: +bufsize=1232 +dnssec +nocrypto +multi -t It serves me well, mostly. Sometimes it bites me as well. In general I'm happy with it. Best regards, -- Marco Davids Research Engineer SIDN | Meander 501 | 6825 MD | Postbus 5022 | 6802 EA | ARNHEM T +31 (0)26 352 55 00 | www.sidnlabs.nl | Twitter: @marcodavids https://mastodon.social/@marcodavids | Matrix: @marco:sidnlabs.nl Nostr: 11ed01ff277d94705c2931867b8d900d8bacce6f27aaf7440ce98bb50e02fb34 OpenPGP_signature Description: OpenPGP digital signature -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
DoH GET not working for me
So, I was trying to enforce a GET with DiG 9.18.1, but according to the pcap it is still a POST. I did this: dig +http-plain-get @doh.example.nl TXT example.com What am I doing wrong? -- Marco smime.p7s Description: S/MIME-cryptografische ondertekening -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
BIND9.18.4 won't compile on my Ubuntu 18.04
It stops with messages such as: ../../bin/delv/delv.rst:109:unknown option: +root Is this a known issue already? It compiled fine on a newer Ubuntu 22.04. -- Marco OpenPGP_signature Description: OpenPGP digital signature -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
make AAAA type the default for dig
Hi, Not sure if this has been proposed before, but I am wondering: Has ISC ever considered to change the default 'dig -t' option from A to ? -- Marco signature.asc Description: OpenPGP digital signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNAME + DNSSEC
On 20/10/2016 14:41, Marco Davids (SIDN) wrote: > For testing-purposes I tried to simulate the situation in sidnlabs.nl: > > dig +dnssec -t ANY _sidn._dnssec-valcheck._1804289384.sidnlabs.nl ERROR! That should be: dig +dnssec -t ANY _sidn._dnssec-valcheck._1804289384.dname.sidnlabs.nl -- Marco smime.p7s Description: S/MIME Cryptographic Signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
DNAME + DNSSEC
Hi, I noticed some inconsistent behavior in a particular setup where a DNAME is involved and I am trying to figure out who is right and who is wrong. Players involved on the resolving side are: Google Public DNS (resolves without an error) BIND (often results in a timeout and a log-rule saying: "unrelated DNAME in answer") Unbound (results in a SERVFAIL) On the authoritative side the players are: PowerDNS BIND NSD The query-type (A yield other results than ANY) The query to test is for example: dig +dnssec -t ANY _sidn._dnssec-valcheck._1804289384.bergzand.nl I believe both bergzand.nl and bergzand.net are hosted on PowerDNS. dig +dnssec -t ANY _sidn._dnssec-valcheck._1804289384.scintilla.nl This domain is served from BIND. For testing-purposes I tried to simulate the situation in sidnlabs.nl: dig +dnssec -t ANY _sidn._dnssec-valcheck._1804289384.sidnlabs.nl sidnlabs.nl is served from BIND, but example.nl (the DNAME) is served from BIND and NSD). I guess I have these question to the reader: - Is it ok for BIND to have a timeout? - Why does Google resolve, why does UNbound result in a SERVFAIL and who is right? - Is there an authoritative server (PowerDNS perhaps?) not doing the right thing? I've been looking to long to this matter so this is the time to ask for your help. It didn't help that DNS-OARCs open BIND-resolver (184.105.193.73) broke down, having the same effect as a timeout). Thanks. -- Marco smime.p7s Description: S/MIME Cryptographic Signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: [OT] Re: configuration error in lists.isc.org
On 07/08/15 02:03, Charles Swiger wrote: So ISC: please fix your list servers, let them rewrite the From headers! How would this help? Changing the From header breaks your domain's DKIM signing; are you asking them to take ownership of your messages and then DKIM sign them on behalf of isc.org That is what the IETF list servers do anyway. Unfortunately they don't rewrite the From headers, thereby breaking the alignment. So in total it doesn't help a whole lot, but it's one step closer to the solution. Regards, -- Marco smime.p7s Description: S/MIME Cryptographic Signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
DNSSE logging and parsing it
Hi, What would be a good way to configure BIND-logging, or rather to filter DNSSEC-validation errors from that logging? Unbound logs stuff like this: Mar 5 12:58:47 xs unbound: [16331:0] info: validation failure example.nl. A IN: No DNSKEY record from 203.0.113.5 for key example.nl.nl. while building chain of trust That's great for parsing and finding domain names with DNSSEC issues. BIND logs various, less unambiguous kinds of messages, like: dnssec.log:05-Mar-2015 12:58:24.767 dnssec: info: validating example.nl/A: got insecure response; parent indicates it should be secure and, for the same request: lame-servers.log:05-Mar-2015 12:58:24.742 lame-servers: info: insecurity proof failed resolving 'example.nl/A/IN': 203.0.113.5#53 It even logs an informational message when the domain is signed, but there is no DS-record in the parent (which to me does not count as a DNSSEC-validation problem): dnssec.log:05-Mar-2015 12:48:37.969 dnssec: info: validating www.example.nl/A: no valid signature found What would be the best, unambiguous string(s) to grep for, in order to find domain names that have validation-problems? Please advise. -- Marco smime.p7s Description: S/MIME Cryptographic Signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNS weirdness
Darcy Kevin (FCA) schreef op 06-01-15 om 19:56: This nameserver is forwarding to 208.67.222.222 and 208.67.220.220. Are those valid and working? OpenDNS, right? -- Marco smime.p7s Description: S/MIME-cryptografische ondertekening ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: localhoast A record?
On 21-03-14 14:03, Casey Deccio wrote: I've adopted a number of zones and most of them contain localhost in a 127.0.0.1 records. I'm curious what current RFC standards state and what the community considers best practice. I would take a look at the query logs for the zones in question. You might be surprised at how many queries are being made by systems that are applying a suffix from the search list because of the lack of of an entry for localhost in the hosts file or the mishandling thereof. To me, an NXDOMAIN-reply seems better than an answer with an A-record to 127.0.0.1 (because that won't be an incentive to fix an apparently broken situation). My advice: forget about localhost entries in your zone files, unless it concerns a special situation, such as domains that are part of your search-list. You may want to consider adding it in such a case (although I don't do so). But if you do, don't forget to add an -record for ::1 as well ;-) Regards, -- Marco smime.p7s Description: S/MIME Cryptographic Signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Sporadic but noticable SERVFAILs in specific nodes of an anycast resolving farm running BIND
On 05/03/14 15:15, Klaus Darilion wrote: Does it only happen for IPv6 DNS requests? Maybe it is related to this: https://open.nlnetlabs.nl/pipermail/nsd-users/2014-January/001783.html Or, less likely, this: http://marc.info/?l=linux-netdevm=139352943109400w=2 -- Marco ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Who is right?
dig ANY example.org @.. Google Public DNS: -- returns DS: no BIND 9.9.3-P2: -- returns DS: yes Unbound 1.4.20: --- returns DS: no Personally I don't care much, but perhaps someone on this list has a strong opinion about these differences that I should know about? Thank you. -- Marco smime.p7s Description: S/MIME Cryptographic Signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Configuring DNSSEC for child domains
Hi Jaap, On 05/06/13 16:09, Jaap Winius wrote: 2.) http://dnsviz.net/d/zuid.dapadam.nl/dnssec/ This shows two DS records in the parent zone, one not secure and one bogus, and three DNSKEY records in the child zone, none of which are secure. Perhaps you could remove ns[12].transip.net from your NS-set and try again? It seems as if these name servers are causing some problems. (see attachment) http://dnsviz.net/d/zuid.dapadam.nl/responses/ Regards, -- Marco dig +dnssec DS zuid.dapadam.nl @ns2.transip.net. ;; Got bad packet: extra input data 424 bytes 07 95 84 00 00 01 00 03 00 00 00 01 04 7a 75 69 .zui 64 07 64 61 70 61 64 61 6d 02 6e 6c 00 00 2b 00 d.dapadam.nl..+. 01 04 7a 75 69 64 07 64 61 70 61 64 61 6d 02 6e ..zuid.dapadam.n 6c 00 00 2b 00 01 00 01 51 80 00 3a 00 00 08 01 l..+Q..: 00 00 00 05 00 00 00 00 00 00 00 00 00 00 27 63 ..'c 32 65 31 38 37 63 30 62 64 31 33 32 37 62 37 65 2e187c0bd1327b7e 66 61 62 62 64 36 34 36 32 65 39 63 64 32 35 64 fabbd6462e9cd25d 35 34 31 35 39 37 04 7a 75 69 64 07 64 61 70 61 541597.zuid.dapa 64 61 6d 02 6e 6c 00 00 2b 00 01 00 01 51 80 00 dam.nl..+Q.. 53 00 00 08 02 00 00 00 00 00 00 00 00 00 00 00 S... 00 00 00 40 64 32 31 32 36 32 65 30 35 62 37 37 ...@d21262e05b77 66 66 33 61 30 39 39 38 33 65 38 37 30 30 37 32 ff3a09983e870072 61 64 63 66 34 63 65 31 61 30 64 66 38 63 33 36 adcf4ce1a0df8c36 36 38 36 36 33 30 31 64 65 66 63 34 61 65 34 33 6866301defc4ae43 35 32 64 33 04 7a 75 69 64 07 64 61 70 61 64 61 52d3.zuid.dapada 6d 02 6e 6c 00 00 2e 00 01 00 01 51 80 00 9e 00 m.nl...Q 2b 08 03 00 01 51 80 51 ab 44 ba 51 83 a9 aa da +Q.Q.D.Q 55 07 64 61 70 61 64 61 6d 02 6e 6c 00 02 a3 b2 U.dapadam.nl 3a 2a 8c 4f 39 7e ff 54 75 ff 0c fb c6 3d ac 5e :*.O9..Tu=.^ b3 a4 ec 0c 52 32 e7 f5 1c a6 89 fe 4a b4 a8 fb R2..J... 98 17 7f b3 68 f1 c8 5c a0 af bc cc 7a 76 e4 26 h..\zv. d8 b5 e4 f7 9e 1b e9 0d b9 b5 14 91 ae 85 af cf 35 c0 d3 4b a1 0f ec b4 cf 81 ad f9 7d 0e bc c3 5..K}... 68 77 6d ac 83 27 79 1b 97 8b 2d 2f 06 d6 1a dd hwm..'y...-/ d2 72 be 4c 4e 87 61 60 68 8f 06 11 f4 c8 04 25 .r.LN.a`h..% d1 38 63 c5 96 e6 4c 4d b4 f3 12 49 d5 00 00 29 .8c...LM...I...) 10 00 00 00 80 00 00 00 smime.p7s Description: S/MIME Cryptographic Signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Dig 9.9.1 AD-bit
Hi, Dig 9.9.1 is setting the AD-bit in queries by default. Does anyone know why? Took me a while to figure out, among other things because Wireshark has a little bug that prevents the AD-bit being shown in queries. (reported as bug 2472 and 7555 on https://bugs.wireshark.org/bugzilla/) Thanks. Regards, -- Marco ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: NSEC3PARAM not honored in inline-signer mode (was Re: BIND 9.9.0 is now available)
Hi, It is not possible to configure NSEC3 as a default in named.conf (on a per zone basis), is it? I would welcome such a feature. I also find it a bit strange that BIND decides to go for NSEC, even when the KSK and ZSK are configured with algorithm: 7 (NSEC3RSASHA1). Thanks. -- Marco On 03/07/12 00:10, Wolfgang Nagele wrote: Hi, Ok that is already a bit better - at least saves a full sign with NSEC first. Wondering though, from a user perspective sending in NSEC3PARAM from the unsigned end seems like the most natural thing to do. Why complicate matters by having to use rndc here? Cheers, -- Wolfgang Nagele Senior Systems and Network Administrator AusRegistry Pty Ltd Level 8, 10 Queens Road Melbourne, Victoria, Australia, 3004 Phone +61 3 9090 1756 Email: wolfgang.nag...@ausregistry.com.au Web: www.ausregistry.com.au The information contained in this communication is intended for the named recipients only. It is subject to copyright and may contain legally privileged and confidential information and if you are not an intended recipient you must not use, copy, distribute or take any action in reliance on it. If you have received this communication in error, please delete all copies from your system and notify us immediately. On Mar 6, 2012, at 6:55 PM, Evan Hunt wrote: According to the docs it should be possible to set NSEC3PARAM on the unsigned version when using inline-signer mode. The signing BIND 9.9 should then decide to use NSEC3, which salt, opt-out, etc. based on this. I have tried this and could not get it to work. The only way to use NSEC3 with the inline signer atm is to run 'rndc -nsec3param' once the zone has been configured. Any hints? You should be able to use 'rndc signing -nsec3param' before the zone is signed. It's working for me: zone example.nil { type master; inline-signing yes; auto-dnssec maintain; file example1.db; }; $ rndc signing -nsec3param 1 0 10 BEEF example.nil $ rndc signing -list example.nil Pending NSEC3 chain 1 0 10 BEEF $ dnssec-keygen -3 example.nil Generating key pair.++ ..++ Kexample.nil.+007+28952 $ dnssec-keygen -3fk example.nil Generating key pair...+++ ..+++ Kexample.nil.+007+04053 $ rndc loadkeys example.nil $ sbin/rndc signing -list example.nil Done signing with key 4053/NSEC3RSASHA1 Done signing with key 28952/NSEC3RSASHA1 $ dig @localhost +short nsec3param example.nil 1 0 10 BEEF -- Evan Hunt -- each@isc.orggg Internet Systema Consortium, Inc. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: NSEC3PARAM not honored in inline-signer mode (was Re: BIND 9.9.0 is now available)
Phil, On 03/07/12 10:27, Phil Mayers wrote: On 03/07/2012 08:50 AM, Marco Davids (SIDN) wrote: I also find it a bit strange that BIND decides to go for NSEC, even when the KSK and ZSK are configured with algorithm: 7 (NSEC3RSASHA1). AS I understand it, NSEC3 incurs overhead at validating resolvers. That being the case, it is unfriendly to use it unless you really need it I don't have a problem with that. It's just that I find the current way BIND works a bit tricky. I would feel more comfortable with an explicit configuration-option in named.conf, rather than a seperate action (being 'rndc signing -nsec3param'). (In the case I *really* want NSEC3 that is, naturally) Regards, -- Marco ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: NSEC3PARAM not honored in inline-signer mode (was Re: BIND 9.9.0 is now available)
On 03-07-12 18:08, Evan Hunt wrote: I also find it a bit strange that BIND decides to go for NSEC, even when the KSK and ZSK are configured with algorithm: 7 (NSEC3RSASHA1). There's no difference between algorithm 7 and algorithm 5 (RSASHA1). The use of a new algorithm number for a previously-existing algorithm is sort of a signaling mechanism: it tells older resolvers that you're using a newer version of the DNSSEC specification than they're equipped to deal with . But it doesn't mean NSEC3 is required, or even expected. Interesting way of looking at it. Algo 7 is mentioned in RFC5155. It tells older resolvers your are using a newer version of DNSSEC. Sure it does, namely a version that supports NSEC3, right? Now why would you want to do that? Because either you are doing NSEC3, or you are planning to do so in the foreseeable future. It's kind of a trade-off, I suppose: - use algo 7 with NSEC allows you to move to NSEC3 without much hassle (but older resolvers won't validate your replies meanwhile) - use algo 5 with NSEC and you have to do a algorithm rollover first when you want to move to NSEC3 (but meanwhile, older resolvers will validate your replies). Are there still any 'older' resolvers around? Maybe not... Anyway, thanks for your insights! -- Marco ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: AW: ipv6 PTR in zone file
On 04/12/11 10:50, walter.jontofs...@t-systems.com wrote: you could use ipv6calc (ftp://ftp.bieringer.de/pub/linux/ipv6/ipv6calc) to calculate the reverse strings. Yes. Or do it 'the BIND way': dig -x 2001:7b8:c05::80:1 | grep ip6.arpa | tail -1 | awk '{print $1}' -- Marco Im Auftrag von Michel de Nostredame Gesendet: Montag, 11. April 2011 20:44 An: bind-users Betreff: ipv6 PTR in zone file Hi BIND Users, I am not sure if my post here is proper or not. If not please kindly guide me to a correct list. I have lot of static IPv6 address needs to add into DNS PTR record. Most of them are server IP addresses and addresses on router interfaces. Compose proper PTR records, without human errors, is highly difficult (compares to IPv4 PTR records), as we encode some customer information into the address. I tried to look into bit-string and soon realized it is already removed from recent BIND versions. Then tried to search $REVERSE and $INVERSE on Google but got no much luck; seems not much development / discussion recently. For example, today we probably do PTR list this, $ORIGIN 0.0.0.0.0.0.d.4.1.a.1.0.1.0.0.2.ip6.arpa. 1.0.1.a.0.0.0.5.6.0.c.1.0.0.5.6 PTR xe-3-0-3-101.ar.par1.fr.netname.net. What I am think about is if there is any potential possibility to compose IPv6 PTR records in ZONE files in a little easier method? something like $ORIGIN $REVERSE(2001:01a1:4d00:).ip6.arpa. $REVERSE(6500:1c06:5000:a101) PTR xe-3-0-3-101.ar.par1.fr.netname.net. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: AW: ipv6 PTR in zone file
On 04/12/11 11:49, Michel de Nostredame wrote: you could use ipv6calc (ftp://ftp.bieringer.de/pub/linux/ipv6/ipv6calc) to calculate the reverse strings. Yes. Or do it 'the BIND way': dig -x 2001:7b8:c05::80:1 | grep ip6.arpa | tail -1 | awk '{print $1}' Beside them, is any potential possibility to have something build-in in BIND config/zone file as kind of beautiful (my, and my team, personal point of view) solution? I wonder if the $GENERATE directive could work for you. Not sure... http://www.zytrax.com/books/dns/ch8/generate.html -- Marco ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Bind 9.8 with dlz and dnssec
Op 10-03-11 18:26, Christian Laursen schreef: On 03/10/11 17:05, Evan Hunt wrote: and hadn't even given any thought to to the problem of supporting DNSSEC, but we can add those features to the roadmap as well if there's user demand. I just want to throw my vote for having DLZ support DNSSEC at some point. Christian, Evan, You might want to play around a little bit with PowerDNSSEC. Even though DNSSEC development is still ongoing, it already looks very promising and I am sure it will serve well as a great source of inspiration for future DLZ developments. http://powerdnssec.org/ -- Marco ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: ad flag for RRSIG queries
On 07/14/10 00:43, Doug Barton wrote: Can anyone explain to me why the 'ad'-flag is set for this query? dig +dnssec -t RRSIG www.forfunsec.org I use BIND 9.7.0rc1, configured to work with the IANA testbed. I'd be interested to see what happens if you upgrade to the latest versions in each branch (the 9.7.x server above What you're seeing sounds like a bug, hopefully one that's been fixed (as it seems to be in 9.7.1-P1). I just upgraded one machine to 9.7.1-P1 (configured to use DLV). Same result... ; DiG 9.7.1-P1 +dnssec rrsig www.iis.se @localhost ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 48545 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;www.iis.se.IN RRSIG ;; ANSWER SECTION: www.iis.se. 6 IN RRSIG A 5 3 60 20100723102502 20100713102502 3932 iis.se. MF5Qq5yBzQ+ZvDvcfGBoVn6ym3EzCOVVqQY2ghVxBoSCQ9Hrh1/0nOj9 39Mr5incAefjg0mXSSvDo9WqFUm1cqUcQ4UJuOoT7VzDiC2OilAxr2xe fo6pivkNlHGIPzbXjSrq65292YIKgQnPXleTtH4HepUmn6bESQI/ioaB 9xk= ;; AUTHORITY SECTION: iis.se. 3545IN NS ns2.nic.se. iis.se. 3545IN NS ns.nic.se. iis.se. 3545IN NS ns3.nic.se. iis.se. 3545IN RRSIG NS 5 2 3600 20100723102502 20100713102502 3932 iis.se. JRJ11qCnEFgVFY0ZDfevfd7Colywb7tlgFXWXOjq0ikqCX8lvcIBKbik RQ+NqwBsHE4aa4E9QLVaruFTg+5tYIKWdonDjk8Kon+8f4oAf9cy9Yjs Ldg0N6wa2HsTlHAq+EdlvXKgZvs8qCkY87iwkVLqn0bp704yacQhVKIQ yXA= ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Wed Jul 14 04:46:41 2010 ;; MSG SIZE rcvd: 428 dig +short chaos txt version.bind @localhost 9.7.1-P1 -- Marco ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
ad flag for RRSIG queries
Hi, Can anyone explain to me why the 'ad'-flag is set for this query? dig +dnssec -t RRSIG www.forfunsec.org How does a validating resolver determine that such an answer is secure? Thank you. -- Marco Davids ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Strange issue - please enlighten me
Hi, I run into an unclear situation while trying to resolve certain domains. It happened when I tried with 9.7.0rc1, 9.7.0b and also with 9.7.0. I dont's have a whole lot of other BIND versions at my disposal, but I found an older one, 9.3.4-P1.2, and that one works fine. One of the domains that suffers from this issue is www.airfrance.fr. It gives a SERVFAIL: ; DiG 9.7.0rc1 www.airfrance.fr @localhost ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: SERVFAIL, id: 65377 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.airfrance.fr. IN A ;; Query time: 1 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Fri Feb 19 19:03:35 2010 ;; MSG SIZE rcvd: 34 Anyone any clue? I am trying to understand why some resolvers handle this query well, while BIND 9.7.x returns a SERVFAIL. dig +trace www.airfrance.fr works as expected. logging says: lame-servers: info: lame server resolving 'www.airfrance.fr' (in 'www.airfrance.fr'?): 193.57.219.253#53 Thank you. Regards, -- Marco Davids ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users