Re: id.server on 9.18.24

[Marco Davids (SIDN) via bind-users]

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

[Marco Davids (SIDN) via bind-users]

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

[Marco Davids (SIDN) via bind-users]

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

[Marco Davids (SIDN) via bind-users]

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

[Marco Davids (SIDN) via bind-users]

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

[Marco Davids (SIDN) via bind-users]

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

Re: Proper Way to Configure a Domain which never sends emails

[Marco Davids via bind-users]

A TXT _dmarc.domain.tld "v=DMARC1; p=reject" might also be useful.

--
Marco

On 19/08/2019 23:31, Kevin Darcy wrote:
> [ Classification Level: PUBLIC ]
> 
> MXes are for *receiving* mail of course. The request is about *sending*
> mail.
> 
> Setting the SPF record to "-all" is probably about the best you can do,
> since AFAIK there is no universally-recognized way to signal "domain X
> never sends mail".
> 
> Ironically, in order to prevent anyone from accepting mail purportedly
> from your domain, you might want to make yourself look as much as
> possible like SPAM or malware.
> 
> Perhaps you could volunteer your domain to be added to one or more of
> the public SMTP blacklists? :-)
> 
>                                                                        
>                                                  - Kevin
> 
> On Mon, Aug 19, 2019 at 10:34 AM Barry Margolin  > wrote:
> 
> In article  >,
>  Ignacio García mailto:y...@ignasi.com>> wrote:
> 
> > Hi there.
> >
> > Thanks for your support. First message to the list, sorry if already
> > posted a similar question, but I haven't found mention anywhere.
> >
> > I have to set up dns records for a domain just for a web site, for
> which
> > we will NEVER send emails (though we might receive some from old
> > customers), so I would like to announce somehow that emails sent from
> > this domain should always be disregarded. I was thinking of
> setting just
> > A and  records for @ and www, NS records, MA records (for
> receiving)
> > and SPF with a record just consisting of v=spf1 -all  , not
> declaring an
> > A and MX records at all. I'm not sure at all this is a proper way of
> > declaring this. In fact, what I would like is to EXPLICITELY mention
> > somehow that we will never send emails from that domain. Could
> anybody
> > help me with this?
> 
> A common practice is to point the MX record to ".".
> 
> -- 
> Barry Margolin
> Arlington, MA



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

make AAAA type the default for dig

[Marco Davids (SIDN)]

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

[Marco Davids (SIDN)]

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

[Marco Davids (SIDN)]

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

[Marco Davids (SIDN)]

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

[Marco Davids (SIDN)]

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

[Marco Davids (SIDN)]

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?

[Marco Davids (SIDN)]

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

[Marco Davids (SIDN)]

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?

[Marco Davids (SIDN)]

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

[Marco Davids (SIDN)]

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

[Marco Davids (SIDN)]

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)

[Marco Davids (SIDN)]

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)

[Marco Davids (SIDN)]

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)

[Marco Davids (SIDN)]

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: Query Regarding NSEC RR in DNSSEC

[Marco Davids]

Hello Gaurav,

You might want to have a look at our whitepaper on 'authenticated denial
of existence' to gain better understanding of this somewhat complicated
aspect of the DNSSEC specification:

https://www.sidn.nl/fileadmin/docs/PDF-files_UK/wp-2011-0x01-v2.pdf

Regards,

--
Marco



On 02/14/2012 08:18 PM, Chris Buxton wrote:
 Briefly, the answer is, the NXDOMAIN response could be replayed by a
 man-in-the-middle attacker. We need to have something to sign, something
 specific to that query. If we just return the zone's SOA record and its
 signature, we're still subject to a replay attack. So we need to prove
 the negative, and that happens by enumerating all the possible positive
 answers near the query.
 
 Regards,
 Chris Buxton
 BlueCat Networks
 
 On Feb 14, 2012, at 9:23 AM, Gaurav kansal wrote:
 
 Dear Team,
  
 We have a Authenticated Response in DNSSEC through trust chain.
 Now my question is why we itself need a NSEC when we get response from
 DNSSEC enabled server authentically.
  
 Means, if a Record exist in DNSSEC, then it replies the answer along
 with RRSIG of that RR.
 AND if domain doesn’t exist, then it can simply give NXDOMAIN and our
 job will be done as we trust that nameserver through trust chain.
 So what’s the need of NSEC??
  
 Thanks n Regards, 
 GAURAV KANSAL 
 9910118448 
 VoIP - 6259 
 Operation And Routing Unit 
 NIC , NEW DELHI
  
 Please don't print this e-mail until  unless you really need, it will
 save Trees on Planet Earth. 
 IPv4 is Over,
 Are your ready for new Network.
  
 ___
 Please visit https://lists.isc.org/mailman/listinfo/bind-users to
 unsubscribe from this list

 bind-users mailing list
 bind-users@lists.isc.org mailto:bind-users@lists.isc.org
 https://lists.isc.org/mailman/listinfo/bind-users
 
 
 
 ___
 Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
 from this list
 
 bind-users mailing list
 bind-users@lists.isc.org
 https://lists.isc.org/mailman/listinfo/bind-users

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: AW: ipv6 PTR in zone file

[Marco Davids (SIDN)]

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

[Marco Davids (SIDN)]

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

[Marco Davids (SIDN)]

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

[Marco Davids (SIDN)]

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

[Marco Davids (SIDN)]

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

[Marco Davids (SIDN)]

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

multithreading for dnssec-signzone

[Marco Davids]

Hi all,

It seems as if my 'dnssec-signzone' runs on one CPU-core only, where as
I would have expected it to run on all four.

Specs:

- Ubuntu 8.04.3 LTS
- bind-9.7.0b1.f1.tar.gz
- Quad-core 'Intel(R) Xeon(R) CPU E5335  @ 2.00GHz' (according to
'/proc/cpuinfo')

I tried 'configure' with and without '--enable-threads', but there is no
notable difference.

I also tried 'dnssec-signzone' with and without the '-n' option. No
difference either.

Can anyone point me in the right direction please?

Thank you so much.

-- 
Marco Davids

___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: DNSSEC closed environment

[Marco Davids]

Eduardo Júnior wrote:

 it's possible configure dnssec only between 2 name servers, first is
 the authoritative and second is the recurisve? The authoritative name
 server would have zones signed and the recursive will do querys and
 validation.

Sure, why not?

I personally prefer my setup whereby I have included the IANA testbed:
https://ns.iana.org/dnssec/status.html.

In other words, I use their root hints and zonefiles in my test-environment.

In fact, I even managed to get an appearantly valid chain of trust all
the way up to my 'home.forfunsec.org' testdomain with it. Quite
instructive and fun to play with. :-)

 And using dig (properly compiled and configured) makes
 requests to recursive  and validation occurs correctly?

Yep, that sounds like it should work.

But you might like 'drill', from NlNetlabs:

http://www.nlnetlabs.nl/projects/ldns/

(sorry, for being a bit off-topic here)

Regards,

-- 
Marco Davids
SIDN

___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users