Re: ksk in a volume
On 2011-06-15 15:51, Noel Rocha wrote: In this situation: - KSK signed ZSK(DNSKEY RR). - ZSK signing others RR of zone. I don't see reason for the KSK be present in operations unless add/delete RR DNSKEY. I had the same idea roughly a year ago. And while you're right, it doesn't change much in practice. I'll explain my case, and assume it applies to you as well. Since you allow dynamic updates, the ZSKs need to be online. I think we can all agree on this. In theory, you could still sign the ZSKs manually with the KSK once not-too-often and keep the KSK offline in between. You believe this makes your zone more secure. However, I don't see any security-benefits in this scenario: If the attacker gets hold of the credentials to update the zone dynamically, he can do so in both cases (KSK online or offline). If your server is compromised, he can add/remove records in both cases. In case of ZSK compromise, you can generatesign new ZSKs in both cases. In case of KSK compromise, you generate new KSKs and upload them to the parent. The only difference is that in the offline case, KSK compromise is a little less likely. So in the end, I decided to leave my KSK online and have BIND automatically perform ZSK rollovers for me (KSKs are needed for this, although you could pre-calculate all needed RRSIGs during all stages of the rollover if you really want to) Greets, Niobos ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Deny MX query
On 2011-05-24 21:58, Warren Kumari wrote: On May 24, 2011, at 1:55 PM, Igor da Silva Cagnin wrote: I have a doubt about querys, as fact I’d like to deny just querys type MX. Other querys types must be available. Is it possible? Yes. 1: Don't list the MX record in your zone. or 2: Have multiple views, one with MX records, one without No, that would return NODATA. The original poster was looking for a deny, which I interpret as REFUSED. Niobos ___ 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
On 2011-03-01 21:00, Torinthiel wrote: On 03/01/11 20:17, fakessh @ wrote: 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. I asked this to OVH.fr somewhere around October 2010. They answered that they were working on it and it would be available soon. I re-asked it mid Februari 2010 to OVH.nl. They answered that it's on their roadmap but they don't have a timing yet... They only could provide me with this forum link: http://forum.ovh.nl/showthread.php?t=963 Greets ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Views based on port number
Hi, For my home use, I'd like to use a DNSSEC-validating recursive resolver, preferably one I control myself. Since I don't want to install a server at home specifically for that, I'm trying to develop an alternative. My current idea is to host the RR on my public server, but I don't intend to serve the world, so I'd like to restrict this service to me, somehow. (I have a dynamic IP) So I was thinking of letting bind run additionally on a high random port, and configure my broadband router to do the matching NATting. That brings me to my actual question: How can I match clients based on the (destination/server) port they used to contact BIND? Is this possible? Or is there a much easier way to solve my problem and am I overly complicating things? And you never know: if anyone has ever installed BIND 9.7 on a dd-wrt box, that would solve my problem as well. Thanks, Niobos ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Silently drop queries for AAAA records
On 2010-12-07 23:31, 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. Actually, this is the desired behavior for IPv6 applications. They prefer v6, so they first try to connect over v6 (hence the request). When they either (1) don't get an IPv6 address or (2) they see that they have no route to that IPv6 address or (3) the v6 connection times out; they fall back to IPv4. Most applications are configurable to only try either v4 or v6. In my humble opinion, you should ask for this last option in your software. As for proving your point in that second case, you can add a bogus IPv6 address and push the client into failure mode (3), which will cause a noticeable delay. Niobos ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC - 1 RRSIG - expires while in cache
On 2010-11-27 13:09, Marc Lampo wrote: Q2: Does Bind automatic resigning take the TTL into account ? (so that it does not resign later then present expiration - TTL) Depending on the configuration: sig-validity-interval Specifies the number of days into the future when DNSSEC signatures automatically generated as a result of dynamic updates (the section called Dynamic Update) will expire. There is an optional second field which specifies how long before expiry that the signatures will be regenerated. If not specified, the signatures will be regenerated at 1/4 of base interval. The second field is specified in days if the base interval is greater than 7 days otherwise it is specified in hours. The default base interval is 30 days giving a re-signing interval of 7 1/2 days. The maximum values are 10 years (3660 days). The signature inception time is unconditionally set to one hour before the current time to allow for a limited amount of clock skew. The sig-validity-interval should be, at least, several multiples of the SOA expire interval to allow for reasonable interaction between the various timer and expiry dates. If your TTL is longer than 7.5 days, bind will NOT resign correctly without this option. greetings, Niobos ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Possible cache poisoning
On 2010-10-26 00:39, The Doctor wrote: My question is how can you detect if a DSN / Domain name has been 'poisoned'? By using DNSSEC ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: No cache for NS RR in public DNS
On 2010-10-15 10:52, Tech W. wrote: Hello, like this domain: blogchina.org I can't get its NS RR in public DNS: dig blogchina.org ns @8.8.8.8 get nothing. From my perspective, blogchina.org has 12 authoritative name servers (as reported by a0.org.afilias-nst.info). ns1.dnspod.net. ns1.qydns1.com. ns2.qyinc.cn. ns1.qydns2.com. q3y1dns1.mydnspod.com. ns6.dnspod.net. ns1.qyinc.cn. ns4.dnspod.net. ns3.dnspod.net. ns2.dnspod.net. q3y1dns2.mydnspod.com. ns5.dnspod.net. If I request the NS records for blogchina.org there, none of them gives an answer section; some (ns1.qydns1.com, ns2.qyinc.cn, ns1,qydns2.com) even time out without any response. Start by checking: * if these are the correct servers? if not, you need to change them via your registrar * if these servers are configured to server your zone? most of them return a SOA, so they seem to know about it * if these servers have correct zone data? none of them returns NS records Greets, Niobos ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: more flexible serial number handling in dnssec-signzone
On 2010-10-15 19:38, Jay Ford wrote: I found myself in need of more flexibility in the way dnssec-signzone handled SOA serial numbers, so I hacked in a way to have the new serial number generated by calling strftime(3) with a user-specified time format. I was on the verge of doing something similar myself a few months ago. After some thinking, I abandoned using dates as serial. All my zones are now dynamic, so BIND takes care of incrementing the serial at every change, either via nsupdate or because of DNSSEC timing. What's the advantage of using a date anyway? I too can see when a zone was last edited, even down to the second, by watching the RRSIG(SOA) timing. just my 2 cents, Niobos ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Reverse Configuration
On 2010-10-15 17:14, João Alberto Kuchnier wrote:
Dispite of that, I'm having some problems with reverse DNS. MxToolBox,
for example, is saying that my reverse DNS is not configured.
That's because it isn't:
if I query for 3.101.198.200.in-addr.arpa (i.e. the reverse lookup for
IP 200.198.101.3), I don't get the delegation that you have configured.
Instead I get an NXDOMAIN with SOA 101.198.200.in-addr.arpa.
In other words: ns.ipaccess.diveo.net.br. is not configured to delegate
the reverse zones to your server. Instead, it responds authoritatively
that this reverse mapping does not exist. Best to verify with them why
they are not delegating correctly
Below is one my reverse configuration on named.conf.local:
zone dataprom.com-0-15.101.198.200.in-addr.arpa {
type master;
file /etc/bind/dataprom.com/rev;
allow-transfer { slave; };
};
$TTL 216000
$ORIGIN 101.198.200.IN-ADDR.ARPA.
Your zone is configured as dataprom.com-0-15.101.198.200.in-addr.arpa.
In the file itself, you leave out the dataprom.com-0-15 part, so the
whole file will be considered as out-of-zone data and ignored.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: more flexible serial number handling in dnssec-signzone
On 2010-10-15 20:23, Jukka Pakkanen wrote: 15.10.2010 20:54, Niobos kirjoitti: What's the advantage of using a date anyway? I too can see when a zone was last edited, even down to the second, by watching the RRSIG(SOA) timing. Time usually goes to one direction only, forward... so using date/time makes sure you are always incrementing the serial. And you even don't need to know the current serial to update it. If that's the reason, dnssec-signzone already supports this: -N unixtime Niobos ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: NSEC3 salt lifetime (and some other DNSSEC params): sane value?
On 2010-09-21 16:46, Kalman Feher wrote: If you don't want someone to know it, don't make it public (at the very least). I agree totally! You'll have to accept that no matter what steps you take, your public information will be available to those who wish to find it. I agree. But I'd argue that there are different grades of public information. My home phone number is public. You can look it up in the (paper or electronic) phonebook. That doesn't mean I'll put it in the footer of every mail/facebook/twitter I send out. Hell, I even use an alias to post to newsgroups instead of my real name. And sure you can figure out who I am, that info is publicly available somewhere (despite my efforts), but I'm not going to hand it to you on a plate. In that sense, I still believe that using NSEC3 over NSEC adds another barrier to those who want to walk your zone. And while it's possible (you could even argue easy) to overcome, it's yet another speed bump. The whole point of NSEC3 was to make zone walking as difficult as brute-forcing the server, not to make it impossible. Taking steps to prevent that is likely to waste more of your time than it will of those looking. Unless you're calculating the NSEC3 hashes by hand, it took me under 1 minute to add an NSEC3PARAM RRset to my zone. And I'm fairly confident that it will take at least 1 minute longer to walk an NSEC3 zone than an NSEC zone. Greets, Niobos ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: NSEC3 salt lifetime (and some other DNSSEC params): sane value?
On 2010-09-21 16:56, Phil Mayers wrote: On 21/09/10 14:43, Niobos wrote: On 2010-09-21 15:32, Kalman Feher wrote: On 21/09/10 8:43 AM, Niobosnio...@dest-unreach.be wrote: I personally find protection against zone enumeration to be a false sense of security. If it's public people will find it. Ask your self what it is that you want publically accessible yet you don't want others to be aware of. I'll reply with a quote from the BIND DNS book: It’s the difference between letting random folks call your company’s switchboard and ask for John Q. Cubicle’s phone number [versus] sending them a copy of your corporate phone directory. That is a poor analogy. Do you have reverse DNS in .in-addr.arpa? Yes Have you timed how long an nmap -sL yoursubnet/mask takes? Because it doesn't take very long for us, and we've got a lot of large subnets. A few seconds Attackers can gain a lot of info from this; Correct certainly not *all* forward lookups, but a lot of them. My zone consists of mostly CNAMEs that map vhosts to physical hosts; you won't find these with .in-addr.arpa. Greetings, Niobos ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: NSEC3 salt lifetime (and some other DNSSEC params): sane value?
Thank you for the excellent advice! On 2010-09-20 18:09, Kevin Oberman wrote: I recommend anyone attempting to secure their DNS read the NIST Computer Security Resource Center document SP800-81 Rev.1, Secure Domain Naming System (DNS) Guide at: http://csrc.nist.gov/publications/nistpubs/800-81r1/sp-800-81r1.pdf It recommends rolling th KSK every 12 to 24 months and the ZSK every 1 to 3 months. These values are unchanged from the original SP800-81 issues back at least two years ago and probably three. Everyone I have spoken with who works with crypto feels that, barring a math breakthough, these numbers are VERY conservative. Very interesting read. However, for my original question, the NIST document says: If the zone is signed using NSEC3 RRs, the salt value should be changed every time the zone is completely resigned Since my zone is only updated dynamically, I'll never *completely* resign my zone... Also, they do mention that [the salt] should be changed on a regular basis to maintain protection against zone enumeration. However, I don't see how it protects the zone from that if I use Daniel Bernstein's method (i.e. guess a name hash it. If it's outside a known hash-range, request the server. Either it's a hit, or it's a new hash-range.) If the hash changes halfway through the procedure, I just rehash all my hits and go on. This is hardly a slowdown at all. Online/offline keys Sometimes this may be a choice, other times legislative or standards compliance will require certain behaviour. I've seen some documents require that even ZSKs remain offline (government agencies mostly), but generally its not considered much benefit if it rolls over reasonably often. KSKs are more commonly recommended to remain offline, but that definition can vary as well. A genuine HSM (Hardware Security Module), is not likely to be found in the bulk of DNSSEC deployments, due to cost, complexity and operational staff skills. Thus most operations will find it easier to generate keys either on the master server (perhaps the only server with key generating software) or close by (another server that is nevertheless online). If you don't use an offline HSM, then your alternatives will require you to have shorter roll over times in my opinion. HSMs are the way to go...if you can afford them. Prices vary a LOT from expensive to WOW! (So does functionality, and DNSSEC will typically take very little.) Because of dynamic DNS requirements, keeping the private ZSK on-line is allowed, even for government sites, though ONLY in cases where dynamic DNS is used or the back-end DNS management system requires it. Government sites may not keep the KSK on-line. See SP800-81r1 Section 9.4 for details. It's a private zone; HSM's are waay too expensive for that purpose! I use DDNS daily, so that requires the ZSK to be online. The KSK can remain offline if I manually resign the new DNSKEY RRset every Lzsk (i.e. every month). I'm not sure I'll have the courage to do this... ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: NSEC3 salt lifetime (and some other DNSSEC params): sane value?
On 2010-09-21 15:32, Kalman Feher wrote: On 21/09/10 8:43 AM, Niobos nio...@dest-unreach.be wrote: I personally find protection against zone enumeration to be a false sense of security. If it's public people will find it. Ask your self what it is that you want publically accessible yet you don't want others to be aware of. I'll reply with a quote from the BIND DNS book: It’s the difference between letting random folks call your company’s switchboard and ask for John Q. Cubicle’s phone number [versus] sending them a copy of your corporate phone directory. On a large scale, manual intervention would make me very concerned with the likelihood of human based outages. I'm even concerned that this will be the problem on my private zone... thank you again for the very insightful info! ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
auto-dnssec resign timers
Hi,
I'm experimenting with the auto-dnssec feature of bind 9.7.0-P1. I know
it's outdated; I did skim over the changelog up until 9.7.2rc2, and
didn't find anything that seems like this issue.
This query demonstrates the issue:
; DiG 9.6.0-APPLE-P2 +dnssec SOA dnssec.dest-unreach.be
@imset.org +norec
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 8632
;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 3
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;dnssec.dest-unreach.be.IN SOA
;; ANSWER SECTION:
dnssec.dest-unreach.be. 86400 IN SOA serv02.imset.org.
hostmaster.dest-unreach.be. 55 3600 3600 172800 300
dnssec.dest-unreach.be. 86400 IN RRSIG SOA 7 3 86400 20100919163624
20100916153624 42614 dnssec.dest-unreach.be.
WBdpqpLCa/5cnMAThAcftrOysfdN8K594WAM+6AMyRPiEpXVF6JRqJWH
N46J3aN6BliM09bA9RxYOoClCcIsJA==
;; AUTHORITY SECTION:
dnssec.dest-unreach.be. 300 IN NS serv02.imset.org.
dnssec.dest-unreach.be. 300 IN NS sdns1.ovh.net.
dnssec.dest-unreach.be. 300 IN RRSIG NS 7 3 300 20100919161438
20100916153624 42614 dnssec.dest-unreach.be.
U6KZzFZecSZNEL0Wp8NxlmjgitQfXbHNt1+S85sZxm9Ti8oNiWMhESts
SmLTmos4VU2yqSo6KOq8mQ/xvoehhw==
;; ADDITIONAL SECTION:
serv02.imset.org. 86400 IN A 94.23.24.89
serv02.imset.org. 86400 IN
2001:41d0:2:1959:21c:c0ff:fe88:6f58
;; Query time: 7 msec
;; SERVER: 94.23.24.89#53(94.23.24.89)
;; WHEN: Fri Sep 17 11:29:14 2010
;; MSG SIZE rcvd: 435
(the dnssec.dest-unreach.be zone is my test zone; publicly available,
but not publicly delegated)
In my opinion, BIND should have resigned this by now: The signature is
valid until a little over 2 days. This means that if the slave would
loose contact with the master right now, it will give out signatures
that will expire before their TTL does.
According to my calculations, RRSIGs should be regenerated zone-expire +
RR-ttl seconds before the RRSIG expires.
For reference, the configuration:
zone dnssec.dest-unreach.be {
type master;
file /var/lib/bind/dnssec.dest-unreach.be.zone;
update-policy local;
auto-dnssec maintain;
dnssec-secure-to-insecure yes;
key-directory /etc/bind/keys;
sig-validity-interval 3;
};
And to be completely honest: the configured slave NS record doesn't
really slave this zone; but BIND shouldn't know or care.
greets,
Niobos
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: auto-dnssec resign timers
On 2010-09-17 12:15, Tony Finch wrote: On 17 Sep 2010, at 10:44, Niobos nio...@dest-unreach.be mailto:nio...@dest-unreach.be wrote: In my opinion, BIND should have resigned this by now: The signature is valid until a little over 2 days. This means that if the slave would loose contact with the master right now, it will give out signatures that will expire before their TTL does. According to my calculations, RRSIGs should be regenerated zone-expire + RR-ttl seconds before the RRSIG expires. You have to manually set the zone expiry time, TTLs, signature lifetime, and re-signing time consistently. The documentation for 9.7.1 says: *sig-validity-interval* * * *Specifies the number of days into the future when DNSSEC signatures automatically generated as a result of dynamic updates (the section called “Dynamic Update” http://dotat.at/tmp/arm97/Bv9ARM.ch04.html#dynamic_update) will expire. There is an optional second field which specifies how long before expiry that the signatures will be regenerated. If not specified, the signatures will be regenerated at 1/4 of base interval. The second field is specified in days if the base interval is greater than 7 days otherwise it is specified in hours. The default base interval is |30| days giving a re-signing interval of 7 1/2 days. The maximum values are 10 years (3660 days).*** Wonderful, exactly what I was looking for. Unfortunately, this mail is the first place where I find a reference to this second field. My Google-searches of bind arm sig-validity-interval only return the single-field descriptions (eg http://training.nlnetlabs.nl/Documentation/bind-arm/Bv9ARM.ch06.html#zone_statement_grammar ); even the man-page of my installation says: sig-validity-interval integer; note the absence of the second field. Is the current version of the ARM available online somewhere? Thx, Niobos ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: auto-dnssec resign timers
On 2010-09-17 19:50, Tony Finch wrote: On 17 Sep 2010, at 14:10, Niobos nio...@dest-unreach.be mailto:nio...@dest-unreach.be wrote: Is the current version of the ARM available online somewhere? http://dotat.at/tmp/arm97/ IIRC the specific version that comes from is 9.7.1p2. Thanks for the quick and accurate answer! Niobos ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
NSEC3 salt lifetime (and some other DNSSEC params): sane value?
Hi, I'm playing around with the different timers of DNSSEC. Usually these timers are a balance between a low overhead vs quick propagation: * A high TTL gives more caching and thus less load on the authoritative server; but it takes a long time for updates to propagate. * A short RRSIG lifetime limits the amount of time old answers can be replayed; but requires regular resigning Or they are a balance between low overhead and security: * A DNSKEY (ZSK or KSK) used for a long time risks being cracked; changing it often requires maintenance. But for the NSEC3 salt, I can't really figure out what the components are... If someone is brute-forcing the NSEC3 hashes (cfr Daniel Bernstein's presentation), changing the salt requires only a minuscule change on their end. I see no reason to change the NSEC3 salt at all. So the question is: what is a normal lifetime of an NSEC3 salt, and for what reason? And while I'm at it: what lifetimes, keylengths and algo's are popular for ZSK's and KSK's? Are your keys stored online or offline? I'm thinking of using ZSK's of 1280bits for a year (since I'm lazy) and KSK's of 2048bits until I feel like changing it (i.e. pretty much indefinitely). This would allow the KSK to be offline, and only needed once a year. I'd like to use NSEC3 with RSA/SHA-512, but that might be unreasonable strong compared to my lazy lifetimes. On the other hand, RSA/SHA1 is more compatible (eg with bind 9.6). My signature lifetime will probably be 3 weeks, resigning every week. With 1 week expire timers, it leaves 1 week of margin to correct errors. Are these values/argo's sane? Thx, Niobos PS: don't try talking me into using NSEC. I'm using NSEC3 because I can, not that it would be any problem at all if they walked my zone. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Forwarding to two servers
On 2010-08-10 02:39, CLOSE Dave (DAE) wrote:
Based on suggestions here, I now have a named.conf file like this:
options { ... };
logging { ... };
zone . IN { type forward; forwarders { PUB; }; forward only; };
zone HOST1 { type forward; forwarders { PRIV; }; };
zone HOST2 { type forward; forwarders { PRIV; }; };
# PUB and PRIV are actually IP addresses, both on the LAN (not WAN)
Does anyone see a hidden gotcha that will bite me later?
Someone naming their host com, org, net or some other existing TLD.
greets,
Niobos
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: dns-sec and Maintaining Human Sanity
Hi, On 2010-08-06 13:24, Martin McCormick wrote: We are upgrading all DNS and DHCP servers to FreeBSD8.0 and my plan was to use bind9.6x. If there is a better version for dns-sec, best to plan to use it now in order to sleigh as much of this dragon which is breathing fire on the edge of town and threatens to move in soon. Definitely consider the 9.7 series! You can enable auto-dnssec which will maintain your signatures for you out-of-the-box. It also supports key rollover, but IIRC doesn't generate new keys at this moment. see for more details: http://www.isc.org/software/bind/new-features/9.7 http://www.isc.org/community/blog/201006/bind-972-and-and-automatic-dnssec-signing Niobos ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Subnet reverse delagation, RFC 2317
On 2010-07-29 09:58, Jukka Pakkanen wrote Recursion is only allowed for the local networks, but why the server thinks recursion is needed in the first place? Because it is: dig -x looks for 200.217.142.62.in-addr.arpa. Your server is not a master for this zone; instead it's master for 128/25.217.142.62.in-addr.arpa. The original request (200.217.142.62.in-addr.arpa.) is mapped via a CNAME to a name inside your zone, but this mapping is done by the ns3.sci.fi. nameserver; hence recursion is needed. Niobos ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Subnet reverse delagation, RFC 2317
On 2010-07-29 15:00, Jukka Pakkanen wrote: Anyway we also have 62.142.217.64/27 IP network (you know what I mean) which should be delegated to our servers, but that still doesn't work. But it's probably a delegation problem. From my point of view, 62.142.217.64 is served by ns3.sci.fi (and its slaves) and is not delegated to you (ns1.qnet.fi). ; DiG 9.7.0-P1 64.217.142.62.in-addr.arpa. ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 5200 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;64.217.142.62.in-addr.arpa.IN A ;; AUTHORITY SECTION: 217.142.62.in-addr.arpa. 3600 IN SOA ns3.sci.fi. hostmaster.sci.fi. 1280318067 3600 900 604800 3600 ;; Query time: 64 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Thu Jul 29 16:04:12 2010 ;; MSG SIZE rcvd: 101 ; DiG 9.7.0-P1 128.217.142.62.in-addr.arpa. ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 20252 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;128.217.142.62.in-addr.arpa. IN A ;; ANSWER SECTION: 128.217.142.62.in-addr.arpa. 14400 IN CNAME 128.128/25.217.142.62.in-addr.arpa. ;; AUTHORITY SECTION: 128/25.217.142.62.in-addr.arpa. 10800 IN SOAns1.qnet.fi. helpdesk.qnet.fi. 201007292 28800 7200 604800 86400 ;; Query time: 1172 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Thu Jul 29 16:05:36 2010 ;; MSG SIZE rcvd: 126 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Multiple masters expected behavior?
On 2010-07-23 22:52, Peter Laws wrote: I would have expected that it would only ask the second-listed master if the first didn't answer ... but I didn't write the code (and haven't read it either! And how would your slave ever pick up an update on second-listed master that (for whatever reason) doesn't propagate to the first? After all, the first is still answering, but with old data. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Signed root - missing RRSIG for delegation?
Hi, It's probably just my lack of knowledge, but there seems to be a missing RRSIG in the root zone. I try to securely resolve example.net. I obviously get a delegation returned (dig output below), but I can't seem to validate that delegation. The delegation itself (and a direct request for net./NS) only yield an RRSIG over the NSEC RRset, not over the NS RRset and not over the glue A-records (which are in bailiwick, and I have no other way to resolve them) Can anyone clarify? thx, Niobos $ dig @l.root-servers.net. +dnssec example.net. A ; DiG 9.6.0-APPLE-P2 @l.root-servers.net. +dnssec example.net. A ; (2 servers found) ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 1174 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 15, ADDITIONAL: 16 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;example.net. IN A ;; AUTHORITY SECTION: net.172800 IN NS a.gtld-servers.net. net.172800 IN NS b.gtld-servers.net. net.172800 IN NS c.gtld-servers.net. net.172800 IN NS d.gtld-servers.net. net.172800 IN NS e.gtld-servers.net. net.172800 IN NS f.gtld-servers.net. net.172800 IN NS g.gtld-servers.net. net.172800 IN NS h.gtld-servers.net. net.172800 IN NS i.gtld-servers.net. net.172800 IN NS j.gtld-servers.net. net.172800 IN NS k.gtld-servers.net. net.172800 IN NS l.gtld-servers.net. net.172800 IN NS m.gtld-servers.net. net.86400 IN NSECnf. NS RRSIG NSEC net.86400 IN RRSIG NSEC 8 1 86400 2010072200 2010071423 41248 . XNB4appdNqmX630pa76WvD7nVhSqz908XQ2DXxLUB2q6VeMsVVPnYppg 5w7zStc5DSFboylq9XeJJXrYJcGmLo9llWj2WNkRa/X4TfGm0P4s1zC5 BDAzvbTYm2KbUv88b3TzZzIxmyyCMWbo8sY+ihJckmkpftg5LAVcU9B6 Ajs= ;; ADDITIONAL SECTION: a.gtld-servers.net. 172800 IN A 192.5.6.30 b.gtld-servers.net. 172800 IN A 192.33.14.30 c.gtld-servers.net. 172800 IN A 192.26.92.30 d.gtld-servers.net. 172800 IN A 192.31.80.30 e.gtld-servers.net. 172800 IN A 192.12.94.30 f.gtld-servers.net. 172800 IN A 192.35.51.30 g.gtld-servers.net. 172800 IN A 192.42.93.30 h.gtld-servers.net. 172800 IN A 192.54.112.30 i.gtld-servers.net. 172800 IN A 192.43.172.30 j.gtld-servers.net. 172800 IN A 192.48.79.30 k.gtld-servers.net. 172800 IN A 192.52.178.30 l.gtld-servers.net. 172800 IN A 192.41.162.30 m.gtld-servers.net. 172800 IN A 192.55.83.30 a.gtld-servers.net. 172800 IN 2001:503:a83e::2:30 b.gtld-servers.net. 172800 IN 2001:503:231d::2:30 ;; Query time: 69 msec ;; SERVER: 199.7.83.42#53(199.7.83.42) ;; WHEN: Fri Jul 16 12:21:13 2010 ;; MSG SIZE rcvd: 711 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Signed root - missing RRSIG for delegation?
On 2010-07-16 12:36, Alan Clegg wrote: .net isn't signed, and you don't sign out-of-zone data (glue and delegation NS records). But org. is signed, and gives the same result. But anyway, it basically boils down to: On 7/16/2010 6:25 AM, Niobos wrote: It's probably just my lack of knowledge Trying to enhance that: Am I correct to state that it's not possible to validate a delegation NS RRset? You can only validate it indirectly by checking if the DS at the parent matches the DNSKEY in the (presumed) child. It appears that DNSSEC was designed to verify from the QNAME back up to the root. I was trying to do it the other way around, hence my confusion. thx, Niobos ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Signed root - missing RRSIG for delegation?
That makes it clear for me; thank you very much! As an unrelated side-note: does anyone know when org.'s DS will be included in the root zone? Niobos On 2010-07-16 14:08, Alan Clegg wrote: Trying to enhance that: Am I correct to state that it's not possible to validate a delegation NS RRset? You can only validate it indirectly by checking if the DS at the parent matches the DNSKEY in the (presumed) child. And that the NS in the child is signed by the ZSK that is signed by the KSK that matches the DS in the parent. The parent is not allowed to sign the NS records (nor glue), as it does not truly 'own' the data -- only the child has that responsibility. It appears that DNSSEC was designed to verify from the QNAME back up to the root. I was trying to do it the other way around, hence my confusion. A leap of faith (trust anchor) provides a validatable zone which contains a DS record which validates a child DNSKEY which provides a validatable zone which ... but you start by doing a query for the QNAME for which you were interested in and then chasing backwards, so yes. I highly recommend http://dnsviz.net as a path to enlightenment. AlanC ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
SRV record question
Hi, I'm a bit confused on how exactly to implement the SRV records. At this moment, it's more an exercise for me, since client software doesn't use them (yet). I have a CALDAV server running on a vhost (apache config). Currently, DNS looks like this: caldav CNAME server server A 1.2.3.4 dead:beef:cafe::1 So in fact, I'm already abusing CNAME to map a service to a host. This is convenient, since the IP is only specified once. (So if it changes, there is no risk of overlooking an entry) The trouble starts when adding SRV records. Spontaneously, I'd add _caldav._tcp SRV 10 10 80 caldav However, RFC2782 explicitly states that: the name MUST NOT be an alias Which would require me to change DNS to look like: caldav A 1.2.3.4 caldav dead:beef:cafe::1 server A 1.2.3.4 server dead:beef:cafe::1 _caldav._tcp SRV 10 10 80 caldav In this configuration, the server's IP is present multiple times, which will lead to mistakes in the future. I can't let the SRV-record point directly to server either, since the vhost-configuration needs the correct Host:-HTTP header. Or am I missing something? Niobos ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC HW Support
On 2010-03-16 15:57, prock...@yahoo.com wrote: I'm trying to figure out how many tests I need to run for an individual product (layer 2, 3, 4, and 7) before I can say it is completely DNSSEC compliant. By definition, any layer 2, 3 and 4 product is DNSSEC-agnostic: DNS with or without SEC-extension is considered payload. If a L2,3 or 4 devices does work with DNS and doesn't work with DNSSEC, it's broken and needs replacement. For completeness: switches and routers are layer 2 and 3 respectively. Layer 7 devices might be affected, since they may preform extensive checking on the DNS-content itself. To answer your question: 0 tests for layer 2, 3 and 4. To be completely compliant, you'd need to run an infinite number of tests for layer 7 devices. I'd test the different algorithms, including some very recent (RSASHA512) and different security statuses (bogus, insecure, secure). Niobos ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Modifying a response
On 2010-02-24 14:09, Peter Andreev wrote: 2010/2/24 Alan Clegg acl...@isc.org mailto:acl...@isc.org Peter Andreev wrote: For example: if user asks for non-existent domain, caching server replies with some address and no-error rcode. _Extremely_ bad idea. Yes, I know, but boss is boss and task is task :). Thank you very much for your answer. You might want to talk to your boss about DNSSEC and how it insures that answer modification is not allowed -- and how it keeps your customers safe and secure and is a good selling point (see the Comcast announcement that was made yesterday). AlanC Oh, DNSSSEC is another headache. These two tasks doesn't influence each other. As far as I can tell, they DO: your modified answers will be marked as BOGUS by DNSSEC and will be thrown away. Niobos ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC: Configuring auto-signed dynamic zone
On 2010-02-16 13:32, Eugene Crosser wrote: Do you think there is an appropriate place somewhere for a small one-page HOWTO? I could document what I did and submit the result... I for one would be interested! Niobos ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC Bogus NXDOMAIN survives authenticating RR
On 2009-12-10 08:49, Niobos wrote: Thank you very much for your help; I'll forward the conversation to the bug-tracking list. Since these are my first DNSSEC experiments, I just wanted to make sure that it wasn't a problem with my understanding of the concept. Niobos This has been confirmed as a security-bug by ISC a while back. Due to the potential exploit, they asked me not to release this information until the fix was released. BIND 9.6.1-P3 now contains the fix: 827. [security] Bogus NXDOMAIN could be cached as if valid. [RT #20712] I can confirm that this version behaves as expected: keeps returning SERVFAIL on bogus NXDOMAIN response. Niobos ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: bindvrs Vulnerability
On 12 Jan 2010, at 17:15, Lightner, Jeff wrote: For BIND blocking the version keeps the auditors from asking the question since they don't know base version let alone extended version. Which tells more about the auditors than about the feature to do so ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Is an IPv6-only glue/delegation record a problem in a world of IPv4?
On 11 Jan 2010, at 18:29, Mathew J. Newton wrote: Specifically, the Dig tool at http://www.kloth.net/services/dig.php seems unable to resolve my records and I can't help but feel it's a problem at my end rather than theirs! It's their end The domain is v6ns.org, and the record I am attempting to query for is ns1.v6ns.org - here's what the Kloth Dig tool gets: v6ns.org. 86400 IN NS ns1.v6ns.org. v6ns.org. 86400 IN NS ns2.v6ns.org. ;; Received 150 bytes from 199.249.112.1#53(A2.ORG.AFILIAS-NST.INFO) in 4 ms If I retry this DNS-query, I get: ; DiG 9.4.3-P3 @A2.ORG.AFILIAS-NST.INFO ns1.v6ns.org. ; (2 servers found) ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 52072 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 4 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;ns1.v6ns.org. IN A ;; AUTHORITY SECTION: v6ns.org. 86400 IN NS ns1.v6ns.org. v6ns.org. 86400 IN NS ns2.v6ns.org. ;; ADDITIONAL SECTION: ns1.v6ns.org. 86400 IN A 77.103.161.36 ns2.v6ns.org. 86400 IN A 77.103.161.36 ns1.v6ns.org. 86400 IN 2a01:348:133::a1 ns2.v6ns.org. 86400 IN 2a01:348:6:a1::2 ;; Query time: 28 msec ;; SERVER: 2001:500:40::1#53(2001:500:40::1) ;; WHEN: Mon Jan 11 20:26:17 2010 ;; MSG SIZE rcvd: 150 Which seems perfectly valid for a v4v6 delegation. I set the domain up to experiment with IPv6, which could be why I've got a problem... Shouldn't, but might... I'm running a v4-v6 DNS right now and I've been through some trouble to get it working... I have a single DNS server with a IPv4 address and two IPv6 addresses. The zone file is as follows: $ORIGIN v6ns.org. $TTL300 @ IN SOA ns1.v6ns.org. dns.newtonnet.co.uk. ( 2010012000 ; Serial 14400 ; Refresh 7200; Retry 950400 ; Expire 300 ) ; Negative Cache TTL IN NS ns1.v6ns.org. IN NS ns2.v6ns.org. ns1 IN 2a01:348:133::a1 ns1 IN A 77.103.161.36 ns2 IN 2a01:348:6:a1::2 This is NOT how it's configured in the Glue: ns1.v6ns.org. 86400 IN A 77.103.161.36 ns2.v6ns.org. 86400 IN A 77.103.161.36 ns1.v6ns.org. 86400 IN 2a01:348:133::a1 ns2.v6ns.org. 86400 IN 2a01:348:6:a1::2 Local lookups for ns1.v6ns.org (A and records) work fine, as they also do from MenMice's online Dig tool. So why not Kloth's? Possibly because it's broken. It works fine here; results conform to the zone you listed above. I can't help but feel it is given the lack of an IPv4 A record for ns2.v6ns.org - either as glue in .org or within my own v6ns.org zone. But should this matter? In the absence of an IPv4 A-record for the ns2.v6ns.org delegation in .org shouldn't their Dig attempt to connect to ns1.v6ns.org instead (yes, they are the same machine but noone else knows this but me... and you!)? I'm not a DNS expert, but I think it should. However, currently there IS a A-glue for ns2 Niobos ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: blockhole'd IP receiving referral?
On 19 Dec 2009, at 16:11, Fr34k wrote: Hello, Chris, I believe you are correct. That is, blackhole applies to the sending of queries in addition to the receiving of queries. Let me explain. I discovered this the hard way. I had a /24 in the blackhole because it contained abusive clients. Within this /24 sat two legitimate authoritative name servers (ANS). Our clients could not get responses from these ANS servers because they were within the /24 blackhole. The solution was to make an exception for these two ANS servers. This is fine in that the blackhole function is doing its job well! However, we have a few /16s among our blackhole networks and to manage an exception list of legitimate ANS servers contained within will be unmanageable. So, how to stop the abuse without impacting legitimate client queries? I think the solution here would be to permit allow-recursion ( mynets;) clients to query and get responses from blackhole ( badnets; } networks in some way. Does such a solution, or equivalent, exist? If so, can someone share? I haven't tested this, but I think this might do what you ask for: Remove the blackhole-statements from the config; instead add these rules to iptables, ipfw or equivalent: * Allow related or established packets to the DNS port * Drop incomming DNS-requests from the blackhole nets This will basically allow replies, but drop requests. Greets, Niobos ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC Bogus NXDOMAIN survives authenticating RR
Could you try this lookup? dig +dnssec removed.dnssec.dest-unreach.be I see now what you mean. Even though I have added your DNSKEY as trusted key, I get SERVFAIL on the first query and NXDOMAIN on the second, without BIND doing any additional outgoing queries. This is the same behavior I'm observing. One of your name servers returns unsigned NXDOMAIN responses with a higher serial number than the master server: I didn't configure the zone by the book; I corrected that now, but the results remain the same. serv02.imset.org returns a signed NXDOMAIN response with serial 2009081781. That corresponds to BIND's error message: | error (insecurity proof failed) resolving 'removed.dnssec.dest-unreach.be/A/IN': 213.251.188.140#53 The response is indeed signed, but the signature should *fail* validation, since there is no covering NSEC3 for the looked-up record. Do I understand the error correctly like this: BIND failed to prove the domain to be insecure, hence, the NXDOMAIN response should have a correct signature, hence, the response it got is bogus? Could the problem be that the authenticating RR somehow considers this domain to be insecure when looking up removed? That might well be the case, although I would expect BIND not to return unsigned queries for names below a manually configured trust anchor. I removed DLV-validation and manually added your KSK DNSKEY as a SEP, without change in behavior: removed.fnord.dnstest.hauke-lampe.de keeps returning SERVFAIL (as it should). It seems that my resolver is configured identical for both my and your domain; so it's possibly some difference in the served zone that causes this behaviour. What did you change for the removed record? Did you remove only the A and RRSIG? Or also the corresponding NSEC3? In attachement my full (signed) zone-file. It's a test-zone anyway, so I don't think this is a security issue. dnssec.dest-unreach.be.zone.signed Description: Binary data Maybe others have an idea what's happening here and why BIND returns NXDOMAIN responses. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
DNSSEC Bogus NXDOMAIN survives authenticating RR
Hi all, I'm having some problems with implementing DNSSEC with NSEC3. I'm fairly new to DNSSEC, so it is certainly possible that my understanding of the subject is causing me to miss something. Also, I'm not entirely sure this is the correct mailing list, more accurate pointers are welcome. The setup contains two BIND nameservers, both version 9.6.1-P1 on a linux OS (ubuntu 9.10 and gentoo). One is configured as authorative name-server for a (test)zone; the other is configured to be an authenticating recursive resolver. I created a zone with the following entries (besides the standard SOA and NS): * normal A 127.0.0.1 * changed A 127.0.0.1 * removed A 127.0.0.1 I also have two DNSKEY records (one KSK and one ZSK). After signing this zone with the keys, I intentionally modify the signed zonefile to simulate a MITM attack: * I change the changed A record to point to 127.0.0.2 * I remove the removed A record, along with its RRSIG I would expect DNSSEC to catch these changes and reject the bogus responses. When requesting a lookup of normal, I get a NOERROR and the AuthenticatedData flag is set, along with the requested data. When requesting a lookup of changed, I get a SERVFAIL. I'm not sure if this is the expected behaviour, but it seems logical. When requesting a lookup of removed, I get a SERVFAIL as well. However, every subsequent request for removed gets an NXDOMAIN. (dig outputs below) Flushing the caches on the RR with rndc flush causes the first request to be a SERVFAIL again. When I look at the debug output of the RR for channel dnssec, I see no additional entries after the initial request. Log in attachement (sorry for the wrong mime-type; if anyone knows how to convince Mail.app to de this decently, let me know) dnssec.log Description: Binary data According to my understanding, this is a bug, probably in the caching. Can anyone confirm this is actually a bug? Point me to the right config-parameter? Or explain to me why this _isn't_ a bug? Niobos $ dig +dnssec removed.dnssec.omitted ; DiG 9.6.0-APPLE-P2 +dnssec removed.dnssec.omitted ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: SERVFAIL, id: 8658 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;removed.dnssec.omitted. IN A ;; Query time: 603 msec ;; SERVER: 10.omitted.1#53(10.omitted.1) ;; WHEN: Sun Dec 6 19:10:05 2009 ;; MSG SIZE rcvd: 59 $ dig +dnssec removed.dnssec.omitted ; DiG 9.6.0-APPLE-P2 +dnssec removed.dnssec.omitted ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 65296 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;removed.dnssec.omitted. IN A ;; AUTHORITY SECTION: omitted. 3599IN SOA serv02.omitted. hostmaster.omitted. 2009111618 3600 3600 604800 3600 ;; Query time: 946 msec ;; SERVER: 10.omitted.1#53(10.omitted.1) ;; WHEN: Sun Dec 6 19:10:07 2009 ;; MSG SIZE rcvd: 122 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
