14, 2013 at 10:29 PM, Kevin Oberman wrote:
> On Thu, Nov 14, 2013 at 11:19 AM, Marc Lampo wrote:
>
>> Hello,
>>
>> dnsstuff.com gives me all green for DNSSEC of uscg.mil.
>> dnsviz.net gives warnings (not : errors) on all RRSIG's - something with
>&g
y SpecialistNorthrop Grumman IS | Civil Systems
> Division (CSD)Office: 410-965-0746 <410-965-0746>Pager: 443-847-7551
> <443-847-7551>Email: linh.k...@ssa.gov *
>
>
>
> *From:* Marc Lampo [mailto:marc.lampo.i...@gmail.com]
> *Sent:* Thursday, November 14, 2013 1:16 PM
&
And the name server 199.211.218.6 does not seem lame either :
$ dig @199.211.218.6 mx uscg.mil. +dnssec
; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> @199.211.218.6 mx uscg.mil. +dnssec
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61958
;;
Not at this moment :
$ dig @8.8.8.8 mx uscg.mil. +dnssec
; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> @8.8.8.8 mx uscg.mil. +dnssec
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42506
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 9, AUTHORITY: 0
An unwise decision, from security point of view !
You are about to open the DNS channel - public DNS resolving available for
internal clients.
Consequently data leakage, file transfer in/out over DNS become possible ...
As far as the question about internal fake zones is concerned :
if the name s
Precisely !
That is why one of the sanity checks is if NS records exist at all.
If not, no DS records will be added.
And reversely : if all NS records are removed, any DS record will be
removed as well.
Just as Mark Andrews indicated.
Kind regards,
Marc Lampo
On Wed, Feb 6, 2013 at 9:59 AM
.
You need to complete the chain of trust by also signing the parent
testing.net. -
and having its DS information published in its parent net. !
Kind regards,
Marc Lampo
Security Officer
EURid
From: Khuu, Linh Contractor [mailto:linh.k...@ssa.gov]
Sent: dinsdag 17 juli
?
à since the root zone is already algo 8 (RSA/SHA-256)
à since most tld’s are 7 or 8 and most with NSEC3
the Windows DNS service is going to treat most of DNSSEC’d name space as
“unsigned” anyway …
(another argument to switch to Bind, internally ?)
Kind regards,
Marc Lampo
Security
lausible attack vector for
hackers ?
Kind regards,
Marc Lampo
Security Officer
EURid (for .eu)
From: John Williams [mailto:john.1...@yahoo.com]
Sent: 28 June 2012 10:35 PM
To: bind-users@lists.isc.org
Subject: BIND, DNSSEC & AD
I have an environment that hosts a BIND based int
NSSEC related RFC's explicitly state to leave
authority/additional section empty if filling them would lead to the
answer becoming too big and requiring the TC bit to be set.
--> it is not a configuration setting, it's RFC defined.
Kind regards,
Marc Lampo
Security Officer
EURid (for .e
s not
easy ...)
Kind regards,
Marc Lampo
Security Officer
EURid (for .eu)
-Original Message-
...
(Also, if you want to switch to NSEC instead of NSEC3, you can use
'rndc signing -nsec3param none'.)
--
Evan Hunt -- e...@isc.org
Internet Sys
s,
if the signatures are simply ignored.
Kind regards,
Marc Lampo
Security Officer
EURid (for .eu)
-Original Message-
From: michoski [mailto:micho...@cisco.com]
Sent: 24 February 2012 06:01 AM
To: vinny_abe...@dell.com; kob6...@gmail.com; ma...@isc.org
Cc: bind-us...@isc.org
Subject:
ather than "fractions of seconds")
I strongly advice not to forward to external, caching name servers.
Or, if you do, also enable DNSSEC validation
(and forward to an external name server that is at least "DNSSEC aware"
- 8.8.8.8 is not, searches for DS records in the wrong pla
o 3 hours - with built-in, not changeable, max of 7
days)
and
max-cache-ttl : max positive cache time
(defaults to 7 days)
(other values that can be "corrected" are max and min refresh and retry
times,
thus protecting a slave server from "unreasonable" values sent by the
m
Hello,
To be precise :
bind.odvr.dns-oarc.net. validates
but seems to ignore expired (but otherwise valid) signatures.
unbound.odvr.dns-oarc.net. validates without ignoring expired signatures.
Kind regards,
Marc Lampo
Security Officer
EURid vzw/asbl
-Original Message-
From: Spain
ll, have not found yet were Bind 9 shows this ?)
Morale : referral in parent should be identical to (or be a subset) of NS
records at domain level.
Kind regards,
Marc Lampo
Security Officer
EURid (for .eu)
-Original Message-
From: MontyRee [mailto:chulm...@hotmail.com]
Sent: 12 January 2012
ready for DNSSEC,
there will be less and less demand for DLV (didnt I see a message stating
end-of-life ?).
Hope this is somehow helpful
if only to state that you should not expect AD-bit set from name servers
in the authoritative role.
Kind regards,
Marc Lampo
Security Officer
EURid
r "thaw" and "unthaw" zone files - it has been experienced this
triggers
"smart signing" into recalculating (but double check !)
4) Although DNSSEC key's do not expire, do change them regularly :
2-3 months for ZSK's,
1-2 years for KSK's.
Kind
4096 : so the server returns most of
EDNS0 info in the query,
but replaces the UDP payload size by what it accepts itself.
(cfr recent posting of Mark Andrews in IETF dnsext mailing list about
finding this out)
Kind regards,
Marc Lampo
Security Officer
EURid
From: Gaurav Kansal
for the DS of
subdomain.domain.com.
do you get a proper reply with AD bit set ?
(no idea yet about the www.subdomain.domain.com observations)
Kind regards,
Marc
-Original Message-
From: Sergio Charpinel Jr. [mailto:sergiocharpi...@gmail.com]
Sent: 05 October 2011 02:22 PM
To: Marc Lamp
y,
but I'd check if domain.com. itself is properly signed.
Kind regards,
Marc Lampo
-Original Message-
From: Sergio Charpinel Jr. [mailto:sergiocharpi...@gmail.com]
Sent: 05 October 2011 01:57 PM
To: bind-users@lists.isc.org
Subject: DNSSEC SERVFAIL when parent zone has no DS record
Hi
.
Kind regards,
Marc Lampo
Security Officer
EURid
From: McConville, Kevin [mailto:kmcconvi...@albany.edu]
Sent: 04 October 2011 09:10 PM
To: bind-users@lists.isc.org
Subject: DNSSEC Signing & Key Questions
Im new to this list, so please bear with me if these are/seem like
newbie quest
forget to have your caching NS validate DNSSEC answers,
because providing signatures that are ignored by clients
makes the Internet *less* safe)
Kind regards,
Marc Lampo
Security Officer
EURid
-Original Message-
From: Brad Bendily [mailto:brad.bend...@la.gov]
Sent: 27 September 20
Hello,
Do add "forward only;" to this zone statement.
Is this name server available/visible to the Internet ?
--> add "allow-query" statement to limit who can query for your internal
zone.
Kind regards,
Marc Lampo
Security Officer
EURid
-Original Message---
your
root zone ?
Kind regards,
Marc Lampo
-Original Message-
From: Tom Schmitt [mailto:tomschm...@gmx.de]
Sent: 30 August 2011 01:57 PM
To: bind-users
Subject: what does dig +trace do?
Hi,
I have a question: What does dig +trace exactly do?
The reason for my question is:
I have a interna
n the cache.
With that behaviour, it are the (validating) user of that
caching name server that will encounter problems.
I'm unsure this is desirable behaviour,
which I wanted to bring to attention.
Kind regards,
Marc Lampo
-Original Message-
From: Paul Wouters [mailto:p...@xel
g the first one, yields SERVFAIL ...
If I overlooked something obvious,
sorry for the interrupt (but thanks for sending clarifying references).
Thanks and kind regards,
Marc Lampo
Security Officer
EURid
Woluwelaan 150
1831 Diegem - Belgium
marc.la...@eurid.eu
http
that using MS DNS as validating caching name server is
pointless,
as the root uses algorithm 8 and domains with unknown algorithms are
treated as "unsigned".
--> for MS DNS, the chain-of-trust breaks right at the top level, not ?
Kind regards,
Marc Lampo
EURid
Security Officer
-Ori
*temporary* solution, until the remote side DNS administrators get
their thing fixed !!!
Kind regards,
Marc Lampo
Security Officer
EURid vzw/asbl
-Original Message-
From: Dodson, Ron [mailto:ron.dod...@lmco.com]
Sent: 04 August 2011 05:47 PM
To: bind-users@lists.isc.org
Subject: Is th
root. The local caching name server is the only one to know those "new"
root's.)
Kind regards,
Marc Lampo
-Original Message-
From: Feng He [mailto:short...@gmail.com]
Sent: 19 July 2011 07:54 AM
To: Marc Lampo
Cc: bind-users@lists.isc.org
Subject: Re: about the dig
at
I guess not, since "it" does not work ;-)
After deleting all entries, did you :
1) dig @dns.name. ...
or
2) dig @IP.address
or
3) No "@..." argument used at all ?
In cases 1 & 3, dig will need data from /etc/resolv.conf.
Only in case 2 dig can do without.
K
also using this ?
Kind regards,
Marc Lampo
Security Officer
EURid
-Original Message-
From: Stefan Foerster [mailto:c...@incertum.net]
Sent: 29 June 2011 10:57 PM
To: bind-us...@isc.org
Subject: Single nameserver doesn't show signed SOA-RRs
Hello world,
I'm having a proble
Yes, this is a setup I tested (with Bind as name server).
You would be getting answers, not with the AD bit set.
Kind regards,
Marc Lampo
-Original Message-
From: Carlos Vicente [mailto:cvicente.li...@gmail.com]
Sent: 20 May 2011 07:53 PM
To: Marc Lampo
Cc: bind-users@lists.isc.org
SEC2.pdf,
combine info on pages 15+16 (bogus NS) and 17+18 (forwarding NS)
)
Kind regards,
Marc Lampo
Security Officer
EURid
-Original Message-
From: Matthew Pounsett [mailto:m...@conundrum.com]
Sent: 20 May 2011 06:49 AM
To: Carlos Vicente
Cc: bind-users@lists.isc.org
Subject: Re:
yer' [mailto:bortzme...@nic.fr]
Sent: 09 May 2011 01:52 PM
To: Marc Lampo
Cc: bind-users@lists.isc.org
Subject: Re: [DNSSEC] Resolver behavior with broken DS records
On Mon, May 09, 2011 at 01:41:08PM +0200,
Marc Lampo wrote
a message of 28 lines which said:
> So the "error" of
'Stephane Bortzmeyer' [mailto:bortzme...@nic.fr]
Sent: 09 May 2011 01:46 PM
To: Marc Lampo
Cc: bind-users@lists.isc.org
Subject: Re: [DNSSEC] Resolver behavior with broken DS records
On Mon, May 09, 2011 at 01:00:03PM +0200,
Marc Lampo wrote
a message of 47 lines which said:
> 1
Hello,
Just tried with Bind 9.7.2-P3 (in our course environment for our DNSSEC
workshop).
I can *not* confirm this behaviour there :
1 correct DS record,
1 DS record, correct in everything but the algorithm
--> validating caching name servers nicely return answers with "AD" bit
set.
All name se
) signal this (Bind does).
Hope this helps.
Kind regards,
Marc Lampo
Security Officer
EURid vzw/asbl
From: hugo hugoo [mailto:hugo...@hotmail.com]
Sent: 04 May 2011 09:56 AM
To: marc.la...@eurid.eu; bind-users@lists.isc.org
Subject: RE: how to check if a slave zone is expired
Marc
helpdesk to get this corrected.
Kind regards,
Marc Lampo
EURid vzw/asbl
Security Officer
From: hugo hugoo [mailto:hugo...@hotmail.com]
Sent: 04 May 2011 08:53 AM
To: bind-users@lists.isc.org
Subject: how to check if a slave zone is expired
Dear all,
Is there a way to check that
style - attacks glue (A) records anyway
(not CNAME's).
Recommendation :
If you need to refer to other zones (webhosting, "email-in-the-cloud"),
*insist* that they as well implement DNSSEC for their zones !
Kind regards,
Marc Lampo
Security Officer for EURid vzw/asbl
-Original Me
> > Chris,
> >
> > What's the difference between a stub zone and a static-stub zone?
> > I have been thinking they are the same.
>
> With a stub zone, your server would ask the server with bad NS records
for the NS record set, and > would then try to resolve all queries against
the zone using tha
)
Kind regards,
Marc Lampo
From: hugo hugoo [mailto:hugo...@hotmail.com]
Sent: 22 February 2011 12:00 PM
To: bind-users@lists.isc.org
Subject: bind and IPV6
Dear all,
In the scope of the IPV6 deployment, I have been asked if oiyr DNS servers
are IPV6 compliant.
We are now upgradi
re working with the registrar,
You can also consult help pages on EURid.eu website, accessible to
registrars only)
Kind regards,
Marc Lampo
Security Officer
EURid
Woluwelaan 150
1831 Diegem - Belgium
TEL.: +32 (0) 2 401 3030
MOB.:+32 (0)476 984 391
marc.la.
me
server,
even regardless if the bogus name server is DNSSEC aware or not.
Kind regards,
Marc Lampo
Security Officer
EURid
Woluwelaan 150
1831 Diegem - Belgium
marc.la...@eurid.eu
http://www.eurid.eu
___
bind-user
in the RFC
do apply to expired RRSIG's in the cache.
Thanks and kind regards,
Marc Lampo
EURid
-Original Message-
From: Florian Weimer [mailto:fwei...@bfk.de]
Sent: 03 January 2011 10:22 AM
To: Marc Lampo
Cc: bind-users@lists.isc.org
Subject: Re: caching of expired RRSIG's ?
*
f the entire answer.
Thanks and kind regards,
Marc Lampo
Security Officer
EURid
Woluwelaan 150
1831 Diegem - Belgium
TEL.: +32 (0) 2 401 3030
MOB.:+32 (0)476 984 391
marc.la...@eurid.eu
http://www.eurid.eu
Want a .eu web address in your own langua
(I didn't find any -
RFC5155 states the new algorithms - 6 and 7 - *must* be used when NSEC3
is used,
But not a word - unless I overlooked it - about using algorithm 7 and
yet, NSEC ...)
Looking forward to your comments.
Kind regards,
Marc Lampo
Security Officer
EURid
Wo
the TTL into account ?
(so that it does not resign later then "present expiration" - "TTL")
Or is this irrelevant because the answer to earlier question
is that an expired RRSIG in the cache must be refreshed.
Thanks and kind regards,
Marc Lampo
Security Off
DN to your internal
server.
The fact that, on the internal server, that FQDN might itself not be a
delegated name (no NS records)
is of no relevance to the partner name server.
Hope this helps.
Kind regards,
Marc Lampo
Security Officer
EURid
Woluwelaan 150
1831 Diegem -
e : "unexplored
fields" ?
While this gets sorted out, be careful when adding DNSSEC validation to
forwarding name servers :
only if the caching name server(s), to which queries are forwarded, are
DNSSEC aware themselves
will the combination "forwarding" + "validating
ional setting of the
revocation bit is generally considered as best practice ?
This, in my opinion, adds more complexity for the administrator of DNSSEC zones.
Isn't it enough to use the revoke bit only in case of an actual/suspected
compromise ?
Your comments are welcome !
Kind regards,
51 matches
Mail list logo
