Re: Access external hosts with internal split DNS resolver
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 09.08.2015 um 06:58 schrieb Josh Kuo: Add www.mydomain.co.nz to your internal zone, that is one common way to deal with it. With BIND you can keep the common records in a separate file and use include statement to avoid double entry. On Aug 9, 2015, at 12:50 AM, Dave Koelmeyer dave.koelme...@davekoelmeyer.co.nz wrote: On 09/08/15 16:44, Dave Koelmeyer wrote: - lookups to www.mydomain.co.nz fail, where www.mydomain.com is my public webserver defined in my domain registrar's zone file Correction: this should obviously read lookups to www.mydomain.co.nz fail, where www.mydomain.co.nz is my public webserver defined in my domain registrar's zone file. -- Dave Koelmeyer http://blog.davekoelmeyer.co.nz GPG Key ID: 0x238BFF87 ___ 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 Using the same domain with two seperate contents is just bad practice. And when you decide to use DNSSec sometime in the future it will leave your home network inoperable, because the trust delegations won't work anymore. You should use the zone mydomain.co.nz only for public internet hosts and create a subdomain for your homenetwork, e.g. home.mydomain.co.nz. If the hostnames at home don't need to be resolvable in the internet you don't even have to delegate the subdomain. Just create that zone on your home nameserver and make sure your entire home network uses this server as a resolver. That way your home clients will be able to lookup hosts in both zones while clients on the internet will only see the public zone. And concerning your forward first statement, you should change that to forward only. If your ISPs resolvers can't find a hostname there's no need for your home-resolver to try again. It can just accept that the host is not resolvable and pass on the NXDOMAIN to the client. This will speed up you name resolution considerably. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQIcBAEBAgAGBQJVxvVWAAoJECKEz6pWghImK7IP/A0/NShUls9cRKvAJIEHFuBY 9MEDHSBCG6+kj2xuEmkr6el5ciDR9gT8YYHchYGSsZOSL84B+fpmiCAaRdogCEzt MN/jGJivR9Xm902VvzAPzz0zRG0VkQA3C+iyW/VNaqzHIDWOi+iemx/sQR2dKbJb deeruvUZYOw95OOgXvOvsI7vmmKfoZ/RmLFyF4fj2zWRLK/1hzuA/GfkpxkXnnnR 2S2wVMKv2ewPQ8gyEpjEGJ2rSKhWVF/ybk1wDpDD4Kg4HgYuJ+uvxwb9vD34TNsV 2zbKNfnXv69jcHhtPacwbJsFdB8kFM2rXbrhBPZ5CeH+gQ2RDUNKJkeJTDM+Ziem DdPTr7SHxdJGXMGJQq+MTet2NQMsDwAtym0gDSl0fFxBRD9x4L+1azpqucwftEjf +Nl563AsoO7eCgE58w2tJMOtC/b8nGK3YvNOobM87jh/RhoDVQYsTET1iTCxff59 rZVLhyGMwwvC+dVD5OiB90506qDww7gzPmCD1EijDNXiYfYu/GMpIGK13ePcAjoU mzqCyYKaWbXW5fp86ndB6aaTa1PcrFw+WjeygNvF/nQg4JR7yqfA+1/xGPdG/IWy 45IEm1t/lRu7NNpHpw53rVOpNLmLbQLUPE/AbwULkFV6ghOrLsb907545euZkIp/ jZy3D+T7qXH65RwkPZuO =NHT5 -END PGP 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: tsig zone sharing between zones check + scream
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 08.08.2015 um 03:06 schrieb Lawrence K. Chen, P.Eng.: On 2015-08-07 10:08, Heiko Richter wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 07.08.2015 um 08:52 schrieb Lawrence K. Chen, P.Eng.: Gjust noticed that about 12 hours ago, the business office person finally update our KSK with registrar. (where window was last month.) Well, apparently history must repeat 3 years ago, we rolled over from RSASHA256 to RSASHA256... but the person that did all the interaction with registrarswhere the criteria is that they be in position to pay as needed (which did used to be dns administrator/department manager/etcbut when they left the new manager he didn't want us to continue to have that responsibility...but would've taken it...anyhoo) They selected algorithm type as RSASHA1-NSEC3... Which caused a bit of an outage, especially since they went on vacation right after having left it to the last minute. we had a 60 day rollover window)...original I had gone around end of fiscal year, but decided to shift it... Well, this timestill going RSASHA256 to RSASHA256 (I had done the roll from RSASHA1-NSEC to RSASHA256 before it was possible to register do such things with registrar...so only DLV was involvedthough I did run into a problem since I had a DS record in my zone, etc. the mismatch doing one than the other apparently was the wrong way to go...or soemething.) So this time...RSASHA1 (#5) got selected. If you change the algorithm of your KSK it shoudn't be necessary to change your server's configuration. Neither is it necessary to change the TSIG keys. Just dump the keys into your domain's key-directory and bind will eventually import and use them. If you're in a hurry, you can force the import by running rndc loadkeys Of course you will also need to retire your old key and remove them from the zone by running dnssec-keygen -D now -I now And you should (should, not must!) generate new ZSKs, using the same algorithm, so change your ZSK-rollover-script to generate RSASHA1 from now on. But looking at your algorithm you will have a slight problem, which you need to take care of, BEFORE you publish your new key: RSASHA1 is not NSEC3-aware. So if you decide to run with that key, you have to remove the NSEC3-parameters from your zone (if you have any). The TSIG stuff is related to a separate issue I'm trying to resolve caused by upgrading to 9.9.7-P2. While for KSK, I have no intention of change my algorithm, in violation of previous rulings by Chief Info Security Officer just because the business office staff person had changed the algorithm we use when putting up the new DS I had forwarded up to get set with our registrar. No error was made when DS was added for our other domain done at the same time. I sure wish there was an automated way to do our KSK rolloversespecially if they want to do DNSSEC for the 100's of other domains we serve. There are a few registrars available that support api access for changing KSKs. But, on second try today, it got fixed. (though I suspect the first was valid, but differed from how k-state.edu got done. Also not sure what the implications are. That I sent two DS records (per domain) up. And, only the SHA-1 has been entered. Today in fixing the RSASHA1 + SHA1 entry, it was first replaced as being RSASHA256 + SHA256, but then replaced with SHA-1 digest version (though the SHA256 attempt might have been a real error? Nope...the last 4 digits match the SHA256 DS) What's odd is that in all cases, the confirmation email says DNSKEY was Verfied I'd expect that with the two tries today, but how was that possible when they had selected the wrong algorithm? Hmmm, wonder if all they're 'verifying' is the key id? You are not done completely.The DS for your new key has been published in .edu tld. But there is still a DS record for your old KSK there that must be removed. You can check the status here: http://dnsviz.net/d/k-state.edu/dnssec/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQIcBAEBAgAGBQJVxcipAAoJECKEz6pWghImqBwP/A+ExDiOZKrMOP9zIPYNwokn YH8vuIodl3I69tVFBT2S7LdzflhH22kl7+lY4QI7W5aV2RtbANI73MdhDC1ppq1r UxmWyV3eHpHvp4Eh3Z7AC4rHrpmVAEkEj7XAHQQ6jvQt2dogRoSWlPFyh1CsNNUX Vo6xIbBjI1e5sCqObl8JA4in7INrKaMfgTLai7FIyHChpYdbc8/UvJxfMGTPwDyi 5tRzoNj4Zg8WUMrmWfJdmS6cZ3VghZFve9xn8cEI1eVXmUWcgCbIvAS09yr167gA 5ZH0E2I4o91Gs+IXTs46BsQ48xTqt4PXT5ReFcwPkmFZ2Lts+17skV5QVqgfNqHs 8ZfzmXnhGXXdjK9Pba/i0E+fCP3yJERGvqyNMY0MbLjN17JQjCcQ8WsubOpgKcP6 Ga9AyTl9+1NAuQ2qGxfucfPLwGKCD4H9ReYRaBqSJ+zd/gZGgXvwTx+43GpcoWMR Fxvd4Mb1Oy8RJizRX83s0ePhZthHDBUoWhL7tg5MpX1ukSS2DeWmt8eTE5ruH33b /67lRnWGmc1wtPpInvHQ6y/9DkquqTUu+fRE0lJ+xqb+kEgzUh4/mYR+LiYTRogR VyWoQ44En01E81OHGFqB3V2zkCMXECbVIJ5VQLXNsjnFXyVgvkDEc4CJ1F2Up0u4 rvWkm3Cl2H6IC0++9wJ8 =qlZZ -END PGP
Re: do not stupidly delete ZSK files
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 07.08.2015 um 07:16 schrieb Lawrence K. Chen, P.Eng.: On 2015-08-06 19:26, Heiko Richter wrote: Though back then I was still building bind 32-bit, and the hardware as much slower. A full signing was more than 10x longer than our current hardwarewhich can get it done in just under a minute. (usually) The need for speed is some people expect DNS changes to be near instantaneous. So either you have very slow servers, or a really big zone, if it takes a whole minute to sign it. Just use inline-signing and the changes will be instantanious. As soon as nsupdate delivers a change to the master server, it will sign it automatically and send out notifies. Doesn't even take a second, as only the changes need to be signed, not the whole zone. Its big and probably full of a lot of stuff that isn't needed anymore, etc. Though there something weird about the zones too. our ksu.edu zone will have more entries than the k-state.edu one, even though by policy they should be the same, Just one addition aside the face that your network seems to drown in chaos: If the two zones are mandated to be the same, just empty one of them, put a DNAME record in it that points to the other one and make all future changes there. That way you can be sure the two zones are always in sync though I just fixed up delegated subdomain that is only doing .ksu.edu form (the also don't list us as secondaries or allow us to do transfers anymore...which they're supposed to according to policy (and to ensure external resolutionespecially if all their 129.130.x.y addresses become 10.42.x.y or something. Internally we're probably running out of open blocks of IPv4, especially for anything that wants /27 or bigger (such as a /21) It caused problems the first chunk from a reclaimed block was used. The reclaimed block used to be our guest wireless network (which is now a number of are was a growing number of blocks in 10.x.x.x space) The switch to WPA2 Enterprise versus open guest, made it too tempting to take easy way to get online. So it was required that campus resources block access from guest networks. There was no notification that the old guest network wasn't anymore...and its been years now. But, often hear that it should would be nice if I filled these various network blocks with generated forward/reversesI'm rarely in the loop for what and where the blocks are. Anyways...the odd thing I was going with ksu.edu vs k-state.edu...the size of the raw second zones end up fairly close in size so would expect a huge difference in viewing the zones. but, the named-compilezone to convert k-state.edu back into text took a few seconds, while it took minutes to do ksu.edu.same machine, etc.Wonder why, and wonder to what extent I should investigate. But, our master server, is Sun Fire X4170 M2 (dual Xeon E5620's)its bored and a waste most of the time...until a full signing needs to get done. Though it isn't as fun to watch when I was using a T5120 (64 threads)load average would break 100 and set all kinds of monitoring alerts but it chugged along finethough the apps (and their admins) in other containers on it weren't as happy. Years ago, loads exceeding 100 were often fatal and messy, since they used to be caused by problems between ZFS and our old SAN (9985)as much as they didn't want us to, turning of zil was often the fix to make it not happen anymore. The problem went away after we switched to new SAN (which isnt so new anymore...as its end is nearing. I've thought about looking for a solution that I can throw our zone configs enough that would just work, but I largely haven't had time to do that. Or I was hoping to get more backing on enforcing good behavior in my zones. (stop the vanity of wanting 10.x.x.x servers at same level as your subdomain with public.) Not sure how preprocesssing zone files to generate internal / external (/ guest / dr) versions translates into a free ready to go solution :) I commented out the the latter two as the first never did what they wanted, and I heard that the official DR plan was something that got written up back in 2000 and and then shelved to be revisited when there's funding So once we got we got secondaries outside of our netblock (we vanished complete a few times when our Internet connection breaks, and the last major quite a number of sites plus our email were externally hosted During recent DNS outage, i couldn't send replies to co-workersour Office365 tenant said i was an invalid sender :..( It also apparently knocked me off of jabber and stopped having my deskphone forward to my cellphoneor for me to get sms notications of voicemail. But, FreeNode contined to workbefore jabber we had a private channel that we hung out in (while its been a long time since we ran
Re: tsig zone sharing between zones check + scream
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 07.08.2015 um 08:52 schrieb Lawrence K. Chen, P.Eng.:
Gjust noticed that about 12 hours ago, the business office
person finally update our KSK with registrar. (where window was
last month.)
Well, apparently history must repeat
3 years ago, we rolled over from RSASHA256 to RSASHA256... but the
person that did all the interaction with registrarswhere the
criteria is that they be in position to pay as needed (which did
used to be dns administrator/department manager/etcbut when
they left the new manager he didn't want us to continue to have
that responsibility...but would've taken it...anyhoo) They
selected algorithm type as RSASHA1-NSEC3...
Which caused a bit of an outage, especially since they went on
vacation right after having left it to the last minute. we had a 60
day rollover window)...original I had gone around end of fiscal
year, but decided to shift it...
Well, this timestill going RSASHA256 to RSASHA256 (I had
done the roll from RSASHA1-NSEC to RSASHA256 before it was possible
to register do such things with registrar...so only DLV was
involvedthough I did run into a problem since I had a DS record
in my zone, etc. the mismatch doing one than the other apparently
was the wrong way to go...or soemething.)
So this time...RSASHA1 (#5) got selected.
--
So about tsig sharing a zone
Is something like this right? (ignoring any typos ;)
==
key external { algorithm hmac-sha1; secret ; }
key internal } algorith hmac-sha1; secret ; }
options { notify explicit; allow-trasnfer { none; }; }
acl k-state { 129.130/16; 10.130/16; 10.131/16; 10.132/16; ...
10.139/16; 172.21/16; 192.168.x.0/24; 10.0.0.0/24; };
acl internal { !key external; key internal; k-state; }; acl
external { !key internal; key external; any; };
view internal { match-clients { internal; };
allow-transfer { key internal; };
zone ksu.edu { type master; file pri/ksu.campus.signed;
allow-transfer { key internal; int-secs; }; also-notify {
129.130.x.x; 129.130.x.y; 129.130.x.z; }; } zone ads.ksu.edu {
type slave; file sec/zone.ads.ksu.edu; masters { 127.0.0.1 key
external; 129.130.y.y; 129.130.y.z; }; multi-master yes;
also-notify { 127.0.0.1 key external }; }; };
view external { match-clients { external; };
allow-transfer { key external; };
zone ksu.edu { type master; file pri/ksu.edu.signed; also
notify { 129.130.139.150 key external; 129.130.139.151 key
external; 129.130.254.21 key external; }; }; zone ads.ksu.edu {
type slave; file ext/zone.ads.ksu.edu; masters { 127.0.0.1 key
internal; }; also notify { 129.130.139.150 key external;
129.130.139.151 key external; 129.130.254.21 key external; }; };
};
==
I think that's what I'm thinkingthough been so long since I
too break from monitor that I can barely see now
If you change the algorithm of your KSK it shoudn't be necessary to
change your server's configuration. Neither is it necessary to change
the TSIG keys.
Just dump the keys into your domain's key-directory and bind will
eventually import and use them. If you're in a hurry, you can force
the import by running
rndc loadkeys
Of course you will also need to retire your old key and remove them
from the zone by running
dnssec-keygen -D now -I now
And you should (should, not must!) generate new ZSKs, using the same
algorithm, so change your ZSK-rollover-script to generate RSASHA1 from
now on.
But looking at your algorithm you will have a slight problem, which
you need to take care of, BEFORE you publish your new key: RSASHA1 is
not NSEC3-aware. So if you decide to run with that key, you have to
remove the NSEC3-parameters from your zone (if you have any).
Heiko
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)
iQIcBAEBAgAGBQJVxMn8AAoJECKEz6pWghImKzoP/jH2HhwZ13br5Fg1skpqwfiS
C2bQxT4W+sYHa6Vbt2fpCpb62EylnbsAR4zjAFTkipijuL1UErzsRXoghR8D9tq9
miMO+E1P2JE+VVQqeiF2TpJ3+0Phur9cYd3PyJqgaCxG2rfGkAV4NEiReWCdDmOU
OpRaWh2KxoEj/Fh6+RpoTB4yQ5Juvc8RZOmeL8HSuBxpt9Zlh/wMTz3kfg4A2try
OSQ9ZXW128sXmO2ENRqkxETIR6Bm+82YnFQPtNkCsWrxFSaLm0DPxNvZiWF/GEva
OXXrDfDwR60km64VlcdS+aOKlURK/9PZHFj0sg1hyeg5HHSKsRiJ2J2j4p4fsh9Y
/Zpy/nYClA8vvF/Y8juW8RlEid19zJ2Fav+NtkyhnkYLfu222LIKvLChiR1UhUqS
ISlTdXbsM/38p33Spc/MDXad1iCMaX69aEQd/lGGhrb1ZUKhrQ191qo+lgmrL97W
0szd9SOlyvKHDuHsl7J4OloxAQksIsIpvluoqJXP/3I9HzN4mOcKN2VBU49kHbuU
sw9d7LRUgUlKVD5X814CkUcsMQftnAhBEJvHusZ1rVOUDelEiWKxWaMWMDCp5pgN
wS1Jwif4jdNJMfzMXXErUgwj7baAdJMc5rZmG1UXvckQWNitGeqcAxqMfGxlWIGg
WhEdacerUcgmcejFQ7EY
=N3vU
-END PGP 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
Re: [OT] Re: configuration error in lists.isc.org
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 07.08.2015 um 08:29 schrieb Matus UHLAR - fantomas: On Aug 6, 2015, at 4:25 PM, Heiko Richter em...@heikorichter.name mailto:em...@heikorichter.name wrote: Whenever I post something to the list (I'm not using SMTP, I'm using a usenet server to post to comp.protocols.dns.bind), my postmaster address receives DMARC notifications from list members that have employed this wonderful protocol on their servers, telling me my message had been rejected for violating my SPF policy. My SPF record doesn't include lists.ist.org http://lists.ist.org/, of course and it never will. Furthermore it ends with -all so all my messages to the list are being rejected by list members who have spf aware servers. SPF must only check envelope address, not header From: address - it was never designed to do the latter. Correction: - All implementations of SPF always check 2 addresses: - Envelope-From address - From address SPF will fail whenever the client is not authorized to send for either the Envelope-From address or the From address. So while the list server changes the envelope from address, SPF will still fail as the client is not authorized for the From address. On 07.08.15 02:54, Heiko Richter wrote: Just found another solution, that will help with any DMARC-aware server that knows Sender-ID. I just published: heikorichter.name. 60 IN TXT spf2.0/pra ?all This will force DMARC to check only the envelope sender, which is changed by lists.isc.org as /dev/rob0 pointed out earlier How did your SenderID record look before? Before I only had SPF and no Sender ID. Before the change: heikorichter.name. 60 IN TXT v=spf1 include:heikorichter.org -all heikorichter.org. 60 IN TXT v=spf1 mx -all After the change: heikorichter.name. 60 IN TXT spf2.0/pra ?all heikorichter.name. 60 IN TXT v=spf1 include:heikorichter.org -all heikorichter.org. 60 IN TXT v=spf1 mx -all The spf2.0/pra ?all is SenderID, where pra forces the DMARC server to check only the Envelope-Sender against v=spf1 mx -all. If you don't set that, SPF will always check both Envelope-From and Header-From. Note that it's the SenderID specification that is horribly broken (btw, just because of mailing lists) and further any protocol that uses it (does DMARC?) Blaming the ISC mailserver for not changing header address is blaming it for doing something (all?) list servers did years before microsoft came with the braindead SenderID specification that broke this behaviour. You seem to mix up SenderID and SPF. SPF is the thing that is broken as it always checks Envelope- and Header-From. Sender-ID is a way (the only way) to tell SPF it should just check one of them. After publishing the SenderID record the DMARC bounces stopped as the servers just check the Envelope-From now. Before SenderID the only way had been to live with the DMARC bounces or the make the list servers change the Header-From. But with SenderID there's a working alternative. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQIcBAEBAgAGBQJVxM1pAAoJECKEz6pWghImbvoP/ji9zItzVuUmuyMEHVtRJmLy JIZzF3l3KbZtl2J3KCRdMeik7Dc0oOmn/gzbdmmnSwUCfKAjz/qeLihpYYaYEP21 ogM4P6kPE9aWGYIJs143ZpI2/jzK/cvjijxe0VnsfqsvbvXZ2KCbmGMta3trzVBz YtC6aQVmhyPAOaGylEePyhrjUl4vwPqibPVcpYneXgKg0FCysGMjsM3qQmhOLsnW 5vjt9uTKVbSen4TIK8bbwp0D4H+25WepD8mg141G7O1bd+mkgCCfP+L4C6Iiow4+ 8kFUtjCr82Iyb1d7bzIzisQr0YNgorFBW+b71nHa9IAW4ARJiCQ/aXzwY7facJFj 7Z0A4Y9Y0Nb5kEi8Gj3kJ/bHFkugWIoiDyZ+dYipARNEAurWnrA6OWM6n3QNb1Jh GTovUh7LF2Upbk8Hs8B/OR18gMXl6Pciiyd7qN2lKB7T3o5+ePZAGpuH31bSmJxo tKiAs7BIqz8iFw3jwuyVjch8FJciN0gBgoHHWxsFCBYWFXBeQO0BrOVlISX4blT/ Mb6zFvkozMy3rMS+PzO2I6+JiN081wy2l64UdDSPv18gbdjkRNn2LmfYAvRqLEq0 gHrWRcnDrbFT19t9ppGGsBpNwefGzVODy8KguRGEDcm0TcO1/cvds/svQWu7tbAf PNsqZQ+e0n4LxYuMWb8x =g9kt -END PGP 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: configuration error in lists.isc.org
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 07.08.2015 um 08:03 schrieb Lawrence K. Chen, P.Eng.: In looking through the received headers I see that there's no SPF for lists.isc.org Wether or not lists.isc.org was never in question. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQIcBAEBAgAGBQJVxM26AAoJECKEz6pWghImN4kP+wY3EjA+ZmEpkuV1mpNvAk+K KXG2AvDR9jauRzWHmXkKEIfr5sNfNWGECDD3pmpyP9DIOt+aFiKFouMJPK6H6L6U JrmzjmllvU987VZ8aWE/LJK+8VbcxTvBxFzTzKx2Ej09oW8kr5iwOzv6waQ8om/Y KYOh52nPrLJb3gG1u/q39Wl6kSApv4e0YFKJm5nmfOSVPupThf2GnO4nMmr4kMVx TwUKGUihM4pIFsqDa1bsbuAnIpSkZmz69OYqDb0wPAJx42qgc5UOXjvMzlqQsj8Z UEy344CH0nUZR6PU+za/JHLjnUYcmCiRM5slQcC8AS05BEwH9OAS3cnG9kr5PU/n 8GGZXZafnjfJBryuRKd5/TGK002svdi9yJlH2EC9/C+nQCRiqU3vm54W4EgRajIS 8OXHqIA6iPq0Yx73/6HknRvUxhEoeHfDx0vc/QGj7eaQjyfJJb83HWHvrbHFQAYa /vesJ83PI3nF42P2tbNg57OAEB4TmrlUVgWuBv7eeO3QpSCTFt+UgTTHt8JFETC3 xj0f5rlo+nNesneWXoGeGM1jfeBIwzirywY/FFfssqHU5Wqztjal/6XJ8oePTT9/ bE8a35aDrC7DfdC3paepISIFWLYonoHYnjYx7K/Umzea4nXGIhRtTLc9g5pal5SM Qr4uGoS+QIEJ1uStPw0l =9tkl -END PGP 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
configuration error in lists.isc.org
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi! Nothing concerning Bind, but still relevant to all list users: Just wanted to let you all know about a configuration error on lists.isc.org. It doesn't rewrite any email headers, only reflects incoming messages to all list members which leads to problems in SPF-checks. Whenever I post something to the list (I'm not using SMTP, I'm using a usenet server to post to comp.protocols.dns.bind), my postmaster address receives DMARC notifications from list members that have employed this wonderful protocol on their servers, telling me my message had been rejected for violating my SPF policy. My SPF record doesn't include lists.ist.org, of course and it never will. Furthermore it ends with -all so all my messages to the list are being rejected by list members who have spf aware servers. Just wanted to let you all know about it as I can imagine I'm not the only person who has outgoing SPF. And the worst thing: If you have a record ending with ~all your messages will be accepted but probably end up in a spam report container slowly eating away the good anti-spam-reputation your server has. So ISC: please fix your list servers, let them rewrite the From headers! Yours, Heiko Richter -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQIcBAEBAgAGBQJVw+zvAAoJECKEz6pWghImwr4P+wb6hzvJTFK3WYOIpoj5Vw0B CEV4vhkj0vKYaAvui6rwJAtUkcM8C8IvbdhxdM4TiM6Av7wCBi+uhbF8+khZnlJ4 n0RnLcYQTtEpUawTkLz2BXxePkkkoB7/s3/TWEBUSnuW32oLLJgY1/qczazP1jQ3 1hCXhrKYojrUu0bCBgt30PiZCmYIh0MIg9gT2zudSkKdy/AhIIqCoB29SCtIVKYa Yka0Jv3LD+ligZte7CUgdvoRRPFn1i/cOloZKl9hGRUAbQJgDtXgzYhyqSj6kJyB utpYDjbsKNxeec3D64ZFQWRAIjpgD+n2JqaJvnbMibrgdmcoIREcJcgGcmYv7rCJ BHhJx36p2PHdCaiRro/HbGKs3GhjcnUYi6GVOlI2NGa56zv6y1yh25sp3D3PHWfW 8jWtfij6+nTdckCndyIe78n1X85uyBRUYs4g2Uk/9Jd3Ki1hypnqnViiolPlOajZ FF7K0BrTuNFNYdPrbuwGpzXhYBR70wT0SyNb23uqYtn+MqqvZspS43VbkJCghbdh GJ5CmbApUR6IitjJp5TNUaAkqJRbUlZ3Drs9ggLQU9naUFTzoA6vW6sxLTF7WERo cz8D1D6gO97PrmCyDjOqp7csviD8LyaE6q7kdTYT/1azF9RWTaSj8MEL1EC+EVwR r9eWsswM+R33CyzY1Ffa =QZUO -END PGP 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: do not stupidly delete ZSK files
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 07.08.2015 um 03:36 schrieb Carl Byington: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 2015-08-07 at 02:46 +0200, Heiko Richter wrote: Sadly automated KSK rollover isn't supported by most registrars, Yes, but I only need one registrar to support it :) I have python code that uses the gkg.net API to do automated KSK generation and rollover, including publishing the new (and deleting the old) KSKs at the registrar. sadly my registrar supports that only for customers with a volume of at lease 1000 domains -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQIcBAEBAgAGBQJVxBOeAAoJECKEz6pWghImb2AP/j0GOjdi7uq4qU7fGRZ4zmSw 1mC3s83M90xTD4j0Bf9m5ZzVRnN5vLW/7A9PsJxKeXfMI3RXhHKVWG1jHXWMLY9r s1urBB0U0Elw78TP6IgV60caPhx7KWDywwh3rWwE/nZi1JikcGPRcl76wPtu/AOI XsQdE5Cbw/GA6KV/5hWhP9VSrUuxrGyf6fXJtJyau2K2RaMV4zIz0AN1bt14mPFC 4vSZmxk2FlHLsKON7XiSOIQ0GRkbo2rY7YYN7mKDCkkyoCs3vsNanj+RKswgWbND PhQ7C+Q0cUEqFPkSB6JGUtES9FfP+VtIApmzLS6MJQeacClU5CAUlObtGb3uj9vD TnjePRd71W8PK+AYBNWxpO84LqFCNoDhQtz9nKjntJrYM5fTUi30GTKSHkQHJef9 2kjyxrnGfLhMuxMQgcQc0C2k9eEI3bdJU9PaUvYSesyRhoY5qQLXmIQhhjdGA2z0 taZKiHi/FlumppNGP0xK1DIMMLH30oW2H3AlJhSIlxwiD1drp15StecoBNP7W87/ Wfz4hGao6//0QX+CK4T/F/UHBHQOcbc+bTwXQGhQFszYz+F9FrUFEZcdZIkR5jq6 OpEkct+DAGaGviBRmE8L45M+oxC1LY6U9mjOyinN8Z22vELw26zxl0EnVTrR387G +p3keqtDrFYFPvJKuh0+ =X9U2 -END PGP 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: do not stupidly delete ZSK files
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 07.08.2015 um 01:55 schrieb Lawrence K. Chen, P.Eng.: On 2015-08-06 17:54, Heiko Richter wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 07.08.2015 um 00:23 schrieb Lawrence K. Chen, P.Eng.: On 2015-07-31 06:33, Tony Finch wrote: Most zones have four authoritative nameservers, only one of which I manage. Of the three I don't manage, I'm pretty sure at least two have no DNSSEC-specific configuration -- a hint that any DNSSEC records they serve come from this hidden primary. The DNSSEC records come from the zone data like any other records. You don't need any special DNSSEC configuration to act as a secondary for a signed zone - it just works. Is that the case now? I recall when I was initial deploying DNSSEC, DLV required that all my nameservers respond the same. We use NSEC3 on our zones, but at the time our network operator's nameservers didn't support NSEC3, so were absent from their responses. Had to delay until they upgraded their servers (something about needing to upgrade from 5 to 6 first), before we could go DNSSEC. At first I was just going to turn off NSEC3, but our CISO decided we had to have it. Though until earlier this year we used a constant 4 digit salt. (ascii for KS ;) Now I have it generating a new random 16 digit salt, adapted from example from some paper I had read (and each signing generates its own salt... Even though it is apparently still possible to walk a NSEC3 domain, I think it was to more to hide any embarrassment cruft in our zone file. No idea when somebody will decide to finally clean things up. Other than that recollection, I haven't looked into what possible issues we could run into if the capabilities of our outside managed secondaries didn't match the appliance. Like what if those secondaries only supported up to RSASHA256, but appliance with crypo accelerator prefers RSASHA512 (or perhaps some GOST ... or ECDA/SHA384, which aren't in my named builds...still using 0.9.8zlatest - avoids figuring what else depended on itaside from clamav on our virus filters.) Actually, I wonder if a transition to RSASHA512 on my nameservers wouldn't be bad my bind builds are 64-bit. The secondaries don't have to support any encryption algorithms as they will not use them. These encryption algorithms are used to create the RRSIG records (a process running only on the master) and to verify them (a process running only on dnssec-enabled recursive servers). Whenever you update your zone with nsupdate or you run 'rndc sign' on your zone the master creates the signatures and saves them in RRSIG records. Then it sends out notifys to all secondaries, which will re-transfer the zone from the master. From that point on the only thing your servers have to do, is hand out records from the existing zone. The only thing your servers have to support are the record types. So if your server is still living in the stone age and doesn't know about the existence of DNSKEY, RRSIG and NSEC3 resource records, it will probably have problems to handle your zone. But if such a server still exists nowadays, not having dnssec will be the least of it's worries as has missed decades of security updates... Ok, so way back thenthey were running servers that didn't support NSEC3 RRs and it had nothing to do with what algorithm we were using5 for RSASHA1 or 7 for RSASHA1-NSEC3-SHA1. It did stump when the move to RSASHA256 was made that there was a selection with NSEC3 in the name. Though not as freaked out managementsome how my manager was able to calm them down... Modern keys are all NSEC3-aware. Everything that came after RSASHA1 has NSEC3-support. It is automatically enabled as soon as you publish NSEC3-parameters in your zone. I don't recall if there was a conscious decision to go SHA256 or SHA512, except that from messages I had seen most people were doing SHA256. You always have to look at the complete trust-chain from root to you. The trust of your records can only be as high as the weekest algorithm used in the entire chain allows. Root is signed with RSASHA256 at the moment. There is no sence in having a more secure algorithm because anybody who can't crack that algorithm may just attack the weakest link in the chain above you. Also you have to keep in mind that resolvers have to be able to verify your signatures. I used ECDSA in the beginning, but then notices that by far not every dnssec-enabled resolver is able to verify those signatures, so I changed back to RSASHA256 as this is the minimum any resolver needs to know in order to verify root. Though back then I was still building bind 32-bit, and the hardware as much slower. A full signing was more than 10x longer than our current hardwarewhich can get it done in just under a minute. (usually) The need for speed is some people expect DNS changes
Re: do not stupidly delete ZSK files
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 07.08.2015 um 02:35 schrieb Dave Warren: On 2015-08-06 17:26, Heiko Richter wrote: Root is signed with RSASHA256 at the moment. There is no sence in having a more secure algorithm because anybody who can't crack that algorithm may just attack the weakest link in the chain above you. This only holds while assuming similar key rotation schemes, I believe? If the roots are signed with RSASHA256 and rotate every 3 months, while you sign, set it and forget it, you're vulnerable to anyone that can crack RSASHA256 over any period of time. Probably a theoretical difference, if it becomes feasible for someone to crack RSASHA256 in any reasonable level of time, it would be equally feasible to invest in 2x-8x the hardware and start breaking roots in under 3 months. That's why you sould employ automated rollover. For example my ZSKs are changed automatically every month. As the system does this automatically I cannot forget to do it. It's also not hard to implement that, just run a monthly conjob of dnssec-keygen that dumps new keys into the key-directory of every domain and make proper use of -P -A -I and -D switches. Sadly automated KSK rollover isn't supported by most registrars, but my master server send me an email-reminder, whenever a KSK keyfile gets too old because I forgot the rollover -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQIcBAEBAgAGBQJVw//aAAoJECKEz6pWghImtNMQAIh4hGzydUs3zT8IWiSfKP6o rtMb2USayknmy1Z7Uy+hAM7yL9tC+1Qw8e6PqNOVZMGhtADqYvQLyKeXmK/ZHiMF l5i2erDNqgjpk34dICrE+lmvmzuQ8cNqL15qqut+tR8rPQJc4TDb2iuyInU7h1yB JNP2W/hoadnBTVwrvUEsXN+G7AknDushcUpTzzblRQvvt4UPSjD/Ict9tpw2HL2S JrHhwtjeBhuu6IIc0kzQQwyUQi8lgPWSS+5FqlHlkJQ/texB039wxJPmdEqhQgXM GB0ZVsIcNdRZB8eWC/TBt4AQcOKqQFudqMKhDEsTIXDcrExU3F9+Stnwgcfo6VMv 5ScIpgneiE1GgAXozULfDY7coJDlB5h3JcpRd3nPgSpWTl9VpdjHWPeTNzlXNMLu q4VlQRAbCi73hs3L+G0Dy1MW9FQCS5WJ0PZfE8xu53O5D80qpjAEX7+C8wgZd8bg y/OlgZ2hpt0i/7QfIH9fWvGFs3+VgwL2OjkfP3ZdY7k+cpoS5hsyZaRZ+Wf2FpjQ Ze3xx3hf/rb0GyRfSh+8eAjlRlYQbEFPTKBpeViDizqHQ+n8GDt+ug4OSuR2K7GJ eF77ImC6sgfUaLD2+VKoiq5XgdBbF5fg1sPOeKlFVZZJqoIFX8Po7L36nbNbuh+k d4BUpas//FA5QJgGr3IW =lcpn -END PGP 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: Order and Preference Priority in DNS Responses
Am 03.08.2015 um 13:38 schrieb Harshith Mulky: I wanted to understand how Order and Preference Values have an impact on the answers Received from the DNS Server I am asking because, I have 4 records for NAPTR Query, as below carrier1.com 86400 IN NAPTR 50 50“s” “SIPS+D2T” ““ “_sips._tcp.carrier1.com.” carrier1.com 86400 IN NAPTR 90 50“s” “SIP+D2T”““ “_sip._tcp.carrier1.com.” carrier1.com 86400 IN NAPTR 100 100 “s” “SIP+D2U” ““ “_sip._udp.carrier1.com.” carrier1.com 86400 IN NAPTR 120100 “s” “SIPS+D2U” ““ “_sip._tcp.carrier1.com.” I am expecting to receive the answer as _sip._udp.carrier1.com but i receive _sip._tcp.carrier1.com How could I change this? Hi there! That exactly was the query you sent to the server? Why would you expect to recieave the records with priority 100 and preference 100? BTW: As your records all have a different priority (first number) you should sett the preference to 0 in all records. This field is only used to do load-balancing when you have two or more records with the same priority. ___ 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: ERROR : - writeable file 'data/udalgurijudiciarygov.hosts': already in use: /etc/nicnet2007.govdomain:15424 - loading configuration: failure
Am 03.08.2015 um 08:08 schrieb Mukund Sivaraman: Hi Prakash On Mon, Aug 03, 2015 at 10:14:50AM +0530, prakash wrote: Aug 3 09:59:34 govindnsvm named[7436]: /etc/nicnet2007.govdomain:15424: writeable file 'data/udalgurijudiciarygov.hosts': already in use: /etc/nicnet2007.govdomain:15424 Aug 3 09:59:34 govindnsvm named[7436]: /etc/nicnet2007.govdomain:15431: writeable file 'data/bodolandgov.hosts': already in use: /etc/nicnet2007.govdomain:15431 Aug 3 09:59:34 govindnsvm named[7436]: /etc/nicnet2007.govdomain:15445: writeable file 'data/cexhyd2gov.hosts': already in use: /etc/nicnet2007.govdomain:15445 Aug 3 09:59:34 govindnsvm named[7436]: /etc/nicnet2007.govdomain:15452: writeable file 'data/bmcsagaredu.hosts': already in use: /etc/nicnet2007.govdomain:15452 Aug 3 09:59:34 govindnsvm named[7436]: /etc/nicnet2007.govdomain:15459: writeable file 'data/crckozhikodegov.hosts': already in use: /etc/nicnet2007.govdomain:15459 Aug 3 09:59:34 govindnsvm named[7436]: /etc/nicnet2007.govdomain:15466: writeable file 'data/wblcgov.hosts': already in use: /etc/nicnet2007.govdomain:15466 Aug 3 09:59:34 govindnsvm named[7436]: /etc/nicnet2007.govdomain:15473: writeable file 'data/precursorsncbgov.hosts': already in use: /etc/nicnet2007.govdomain:15473 Aug 3 09:59:34 govindnsvm named[7436]: /etc/nicnet2007.govdomain:15480: writeable file 'data/icggov.hosts': already in use: /etc/nicnet2007.govdomain:15480 Aug 3 09:59:34 govindnsvm named[7436]: loading configuration: failure Aug 3 09:59:34 govindnsvm named[7436]: exiting (due to fatal error) See if you have used these data/*.host as values with the file option multiple times in your named configuration. It may be that you have included a config snippet multiple times. Mukund Why use the file option at all on a slave? Of course it is possible, but why should one force the file name of a slave zone? That configuration option is just needed on the master. Bind will assign a filename for your slave zone on its own and you can be sure it will not assign the same name twice ___ 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: Order and Preference Priority in DNS Responses
Am 03.08.2015 um 13:44 schrieb Reindl Harald: Am 03.08.2015 um 13:38 schrieb Harshith Mulky: I wanted to understand how Order and Preference Values have an impact on the answers Received from the DNS Server I am asking because, I have 4 records for NAPTR Query, as below carrier1.com 86400 IN NAPTR 50 50“s” “SIPS+D2T” ““ “_sips._tcp.carrier1.com.” carrier1.com 86400 IN NAPTR 90 50“s” “SIP+D2T”““ “_sip._tcp.carrier1.com.” carrier1.com 86400 IN NAPTR 100 100 “s” “SIP+D2U” ““ “_sip._udp.carrier1.com.” carrier1.com 86400 IN NAPTR 120100 “s” “SIPS+D2U” ““ “_sip._tcp.carrier1.com.” I am expecting to receive the answer as _sip._udp.carrier1.com but i receive _sip._tcp.carrier1.com randomly https://en.wikipedia.org/wiki/Round-robin_DNS Just saying randomly is not quite correct. At least not always. Depends on the setting of rrset-order. ___ 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
DNSSec KSK problem
Hi!
I'm hoping someone here can help me with a problem in my DNSSec
configuration.
I'm running Bind 9 in Debian Jessie and just finished configuring it
with DNSSec for my zones. Everything including automatic key rollover
for the ZSKs is working, except for a slight anomaly with my KSKs:
For some reason the KSK isn't only used to sign the ZSKs, but also to
sign the zone. My server obviously signs the normal records with the
ZSK and the KSK as you can see on this diagnostic site:
http://dnsviz.net/d/heikorichter.org/dnssec/
Strangely for the TLD and the root zone the same flags are set on their
keys (257 for KSK and 256 for ZSK) and their servers seem to do it
right. Their KSKs are only signing the ZSK and their ZSKs are used to
sign the zone.
How can I force Bind to that same behaviour?
Here is my Options-Clause:
options {
allow-query {
any;
};
allow-recursion {
loopback;
v1;
v2;
};
auth-nxdomain no;
directory /var/cache/bind;
disable-empty-zone yes;
dnssec-enable yes;
dnssec-validation yes;
edns-udp-size 1460;
empty-zones-enable no;
forwarders { };
hostname v1.heikorichter.org;
ixfr-from-differences no;
listen-on {
any;
};
listen-on-v6 {
any;
};
max-refresh-time 7200;
max-retry-time 1800;
max-udp-size 1460;
min-refresh-time 900;
min-retry-time 600;
minimal-responses no;
notify yes;
preferred-glue ;
provide-ixfr no;
random-device /dev/urandom;
recursion yes;
request-ixfr no;
rrset-order {
order random;
};
server-id v1.heikorichter.org;
sig-validity-interval 2400;
statistics-file /etc/bind/stats;
transfer-format one-answer;
version Get Lost Pal;
zone-statistics yes;
};
Command used to generate the KSK:
dnssec-keygen -r /dev/urandom -f KSK -a ECDSAP384SHA384 \
-P now -A +100 -R none -I none -D none \
-K /etc/bind/dyn/heikorichter.org heikorichter.org
Command used to generate the ZSK:
dnssec-keygen -r /dev/urandom -3 -a ECDSAP256SHA256 \
-P +2592000 -A +2678400 -R none -I +5443200 -D +5529600 \
-K /etc/bind/dyn/heikorichter.org heikorichter.org
___
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: Block propagation for a specific record A
Am 29.07.2015 um 10:59 schrieb Job: Hello, for a test page purpuose, we would like to avoid propagation only for a specific record A, example: test.domain.com We need to test if users set up our DNS server in ethernet configuration, and they display correctly the test page. But, if test.domain.com propagate, we are not sure they use our DNS server! Is there a way? Thank you! Francesco Within a zone there ist not. But you could create a sub-zone test.domain.com and delegate to it from the first zone. Then you are free to serve it on any server you want, including one of the servers that is already serving domain.com. ___ 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
