Re: Understanding cause of DNS format error (FORMERR)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Gabriele, On 6/24/12 5:57 AM, Gabriele Paggi wrote: > Hello Carsten, > > Thanks for your reply! >> about the FORMERR. This might be caused by a Firewall or other >> middlebox that truncates the large answer containing the NS >> record set for this domain. >> >> I see the same if I try to fetch the delegation NS records from >> the parent domain (microsoft.com) for >> partners.extranet.microsoft.com: > That doesn't explain why I get a correct reply to my query if I use > a Windows DNS or one of the Google DNS (what software do they run?) > or my home ISP DNS (UPC, Netherlands). what we see is that we get different responses for the NS record set for "partners.extranet.microsoft.com": 1) a list of 4 NS records (dns10/11/12/13.one.microsoft.com) with public route-able IPv4 addresses, answer size is around 200 byte 2) a list of 18 NS records (-ptnr-dc-02.partners.extranet.microsoft.com.) with private RFC 1918 addresses and an answer size of above 800 byte. These are internal domain controllers. The answer size of 800 bytes can create the FORMERR issue. I'm using BIND 9.9.1(-P1) and Unbound 1.4.17 here. Today I'm getting answer type 1) from my home and also from a machine in the datacenter, yesterday I'm seen answer type 2) and the FORMERR. The FORMERR I'm seeing is also quite odd, as it has the "AD" flag set, which should normally not appear in an error type of response, but might be caused by a mangled DNS packet: ;; ->>HEADER<<- opcode: QUERY, status: FORMERR, id: 30679 ;; flags: qr rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 I have no explanation of this issue at the moment. To my knowledge Google is using a homegrown DNS resolver, not BIND. Best regards Carsten Strotmann -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/mxZ4ACgkQsUJ3c+pomYHc6QCfeONcluurcPOX4dMqMWDm4pnf SlgAnAxlJ1UQRSdE+WgN28RYVBmo/N03 =DT/n -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: Understanding cause of DNS format error (FORMERR)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Jeffry, On 6/22/12 1:25 PM, Spain, Dr. Jeffry A. wrote: > From what I observed I would conclude that dns11.one.microsoft.com > is a Windows DNS server since it behaves like mine except for the > AA flag not being set in theirs. It might even be a new Windows 2012 DNS server, and it might be an issue with this new version. This is just speculation, but if it is an issue with Windows 2012 DNS, it might be good to be able to isolate that issue soon (so that it can be fixed before Windows 2012 is released). > The missing AA flag and lack of authority and additional records in > their response seems like improper behavior to me, but I don't know > whether or not the DNS protocol actually requires this. Apparently > BIND 9.9.1-P1 is able to handle this situation. my BIND 9.9.1-P1 showed FORMERR yesterday, but shows the same good answers that you report today. What is see today when I send a direct query to dns10.one.microsoft.com. (or dns11/12/13) is that both AA (Authoritative Answer) and AD (Authenticated Data) flags are set, but the zone does not seem to be DNSSEC signed (no RRSIGs, no DNSKEY): bash-3.2# dig partners.extranet.microsoft.com. INNS @dns11.one.microsoft.com. +dnssec ; <<>> DiG 9.9.1-P1 <<>> partners.extranet.microsoft.com. IN NS @dns11.one.microsoft.com. +dnssec ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40230 ;; flags: qr aa ra ad; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;partners.extranet.microsoft.com. INNS ;; ANSWER SECTION: partners.extranet.microsoft.com. 10 IN NS dns11.one.microsoft.com. partners.extranet.microsoft.com. 10 IN NS dns10.one.microsoft.com. partners.extranet.microsoft.com. 10 IN NS dns13.one.microsoft.com. partners.extranet.microsoft.com. 10 IN NS dns12.one.microsoft.com. dns11.one.microsoft.com. 10 IN A 94.245.124.49 dns10.one.microsoft.com. 10 IN A 131.107.125.65 dns13.one.microsoft.com. 10 IN A 65.55.31.17 dns12.one.microsoft.com. 10 IN A 207.46.55.10 ;; Query time: 37 msec ;; SERVER: 94.245.124.49#53(94.245.124.49) ;; WHEN: Sun Jun 24 10:00:54 2012 ;; MSG SIZE rcvd: 228 Having AD-Flag set on an non-DNSSEC zone might be a protocol violation, and that might be the cause of FORMERR. Best regards Carsten Strotmann -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/myqQACgkQsUJ3c+pomYGzyQCdF6q+TeWUmA4TWYgiOn6pA0ha HHgAn2Amo54kuiNEIJ4hU1kXOwjnY7Pb =7x6l -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: Understanding cause of DNS format error (FORMERR)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, On 6/24/12 10:07 AM, Carsten Strotmann (private) wrote: > It might even be a new Windows 2012 DNS server, and it might be an > issue with this new version. This is just speculation, but if it is > an issue with Windows 2012 DNS, it might be good to be able to > isolate that issue soon (so that it can be fixed before Windows > 2012 is released). I did some tests with the release candidate version of Windows 2012, and I could not reproduce the error. Windows 2012 internal version number is 6.2 (6.2.8400) and it does not implement the "version.bind" request (returns a NOTIMPL error). However the dns11.one.microsoft.com DNS server returns bash-3.2# dig @94.245.124.49 txt ch version.bind ;; Warning: query response not set ;; Warning: Message parser reports malformed message packet. ; <<>> DiG 9.9.1-P1 <<>> @94.245.124.49 txt ch version.bind ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11512 ;; flags: aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;version.bind. CH TXT ;; ANSWER SECTION: version.bind. 1476526080 IN TXT "Microsoft DNS 6.1.7601 (1DB14556)" ;; Query time: 36 msec ;; SERVER: 94.245.124.49#53(94.245.124.49) ;; WHEN: Sun Jun 24 10:26:11 2012 ;; MSG SIZE rcvd: 76 which is Version Product Milestone Service branch 6.1.7600.16xxx Windows Server 2008 R2 RTM GDR I'm now setting up a Windows 2008R2 DNS Server with the latest patches in the test lab to see if I can recreate the issue. Best regards Carsten Strotmann -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/m1ioACgkQsUJ3c+pomYEXWQCfYge8Sjqa4YIhztZLZt5Z9PRp WuYAnjxfbhVJPRm9y31CKPiO/7wCp/fv =oS8C -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: Seeking Advice on DNSSEC Algorithm Rollover
On Sat, 2012-06-23 at 22:34 +, Spain, Dr. Jeffry A. wrote: > I'm experimenting with rolling over my DNSKEYs from algorithm 7 to 8. > The Bv9ARM doesn't discuss this procedure explicitly as far as I can > tell, but section 4.9 presents some clues. I'd like to ask the experts > on this list if the following procedure might accomplish an algorithm > rollover cleanly. Before in-line signing existed, I rolled my keys from algorithm 5 to 8. I was thus using dnssec-signzone to perform the signing. I had also generated my own keys, both KSK and ZSK. ZSK's and KSK's up until then were running their own life-cycles independently from each other. I thought this 'independence' was good as DNSSEC events would happen spread around the year. I discovered that if there was not at least one KSK and ZSK of the same algorithm, dnssec-signzone would fail. If one goes with defaults, KSK life of one year and ZSK of one month, effectively to roll a key algorithm and without forcing the roll-over by removing all the old key/algorithm at the same time, you have to wait for a KSK to 'expire' then add a new algorithm key pair together. As soon as the last old algorithm KSK expires, there must no longer be any old algorithm ZSK's left, but old algorithm ZSK's must be around until this event. That is - at the time of roll-over - you have a KSK/ZSK pair using the old algorithm and a pair using the new algorithm, obviously with appropriate DS's in the Parent. (That should make sense) So, if you only have a very few signed zones, its possibly easier to resign them from scratch, or force a roll-over. (Avoid the pain!) If you re-do everything at the same time - then DNS signing events may no longer be scattered around the year - maybe not a good thing. I'd expect in-line signing to be of a similar nature unless algorithm 7 and 8 keys can as such 'speak for each other'. My advice, test mixing old and new algorithm keys by signing with dnssec-signzone and presume the same rules exist for in-line signing too. I'd look for a solution that 'upgrades' a zone to using a new Key algorithm at the scheduled time of a KSK roll-over. I'm sure you'll post the results here! -- . . ___. .__ Posix Systems - (South) Africa /| /| / /__ m...@posix.co.za - Mark J Elkins, Cisco CCIE / |/ |ARK \_/ /__ LKINS Tel: +27 12 807 0590 Cell: +27 82 601 0496 smime.p7s Description: S/MIME cryptographic signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: Seeking Advice on DNSSEC Algorithm Rollover
> I don't think that bind trying to sign with non-existent key will do any harm > - probably just warning. > But it's simpler - change metadata of the key - set deletion time to the time > you want the key to be deleted (like DS deletion time+TTL). > Bind with auto-dnnsec allow re-reads the metadata and should remove the key > and all the signatures at that time. > You don't need nsupdate nor update-policy for that. Thanks very much. My experience with changing the timing metadata or removing the key files is that named issues a warning like the following: zone /IN: Key // missing or inactive and has no replacement: retaining signatures. In this circumstance none of the RRSIGs or NSECs are removed. They sit there indefinitely even after the RRSIGs expire. Best regards, Jeff. Jeffry A. Spain Network Administrator Cincinnati Country Day School ___ 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: Seeking Advice on DNSSEC Algorithm Rollover
> I discovered that if there was not at least one KSK and ZSK of the same > algorithm, dnssec-signzone would fail. If one goes with defaults, KSK life of > one year and ZSK of one month, effectively to roll a key algorithm and > without forcing the roll-over by removing all the old key/algorithm at the > same time, you have to wait for a KSK to 'expire' then add a new algorithm > key pair together. As soon as the last old algorithm KSK expires, there must > no longer be any old algorithm ZSK's left, but old algorithm ZSK's must be > around until this event. > That is - at the time of roll-over - you have a KSK/ZSK pair using the old > algorithm and a pair using the new algorithm, obviously with appropriate DS's > in the Parent. > (That should make sense) That sounds like it is worth a try. My experience is that when keys from only one algorithm are in place and those keys go inactive, then named issues warnings "Key // missing or inactive and has no replacement: retaining signatures", and the RRSIGs and NSECs are not removed. Maybe with the second algorithm's keys already in place and the zone signed by them, the behavior will be different. I will report back on this. > So, if you only have a very few signed zones, its possibly easier to resign > them from scratch, or force a roll-over. (Avoid the pain!) If you re-do > everything at the same time - then DNS signing events may no longer be > scattered around the year - maybe not a good thing. I'm pretty sure that I can resign from scratch as follows on the inline signing slave: 1) Remove the key files from the old algorithm. 2) Remove the zone files, both signed and unsigned. 3) Increment the SOA serial number on the unsigned zone on the stealth master to something greater than the SOA serial number of the signed zone on the inline signing slave. 4) Reload the zone on the inline signing slave. I will also report back on this. > I'd expect in-line signing to be of a similar nature unless algorithm 7 and 8 > keys can as such 'speak for each other'. > My advice, test mixing old and new algorithm keys by signing with > dnssec-signzone and presume the same rules exist for in-line signing too. > I'd look for a solution that 'upgrades' a zone to using a new Key algorithm > at the scheduled time of a KSK roll-over. Based on testing since my initial post, I have determined that any solution requiring the use of nsupdate isn't going to work. In my scenario where the zones are slaves transferring data from a stealth master and doing inline signing, i.e. the bump-in-the-wire concept, named won't even start with "update-policy local" in the configuration. It considers "update-policy local" a configuration error in zones of "type slave". As I think about this issue more, it seems like a job for rndc. For example, I would like to suggest that there be a command "rndc signing -algclear ", which would immediately remove DNSKEY, RRSIG, NSEC(3), and any other records pertaining to from . It would be used in the following procedure after the keys for the new algorithm are already in place and the zone has been signed by them: 1) "rndc signing -pause " (to pause temporarily "auto-dnssec maintain" signing activities). In my previous post I had suggested the syntax "rndc pause-signing " but this seems more consistent with existing "rndc signing" syntax. 2) Remove the key files belonging to the old algorithm. 3) "rndc signing -algclear " 4) "rndc sign " (to immediately resume "auto-dnssec maintain" signing activities) or wait for dnssec-loadkeys-interval to elapse. > I'm sure you'll post the results here! I will. Thanks again for your input. Jeff. Jeffry A. Spain Network Administrator Cincinnati Country Day School ___ 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: Seeking Advice on DNSSEC Algorithm Rollover
>> I discovered that if there was not at least one KSK and ZSK of the same >> algorithm, dnssec-signzone would fail. If one goes with defaults, KSK life >> of one year and ZSK of one month, effectively to roll a key algorithm and >> without forcing the roll-over by removing all the old key/algorithm at the >> same time, you have to wait for a KSK to 'expire' then add a new algorithm >> key pair together. As soon as the last old algorithm KSK expires, there must >> no longer be any old algorithm ZSK's left, but old algorithm ZSK's must be >> around until this event. >> That is - at the time of roll-over - you have a KSK/ZSK pair using the old >> algorithm and a pair using the new algorithm, obviously with appropriate >> DS's in the Parent. >> (That should make sense) > That sounds like it is worth a try. My experience is that when keys from only > one algorithm are in place and those keys go inactive, then named issues > warnings "Key // missing or inactive and has no > replacement: retaining signatures", and the RRSIGs and NSECs are not removed. > Maybe with the second algorithm's keys already in place and the zone signed > by them, the behavior will be different. I will report back on this. This appears to have worked perfectly. Again I started from a position where there were two sets of keys in place, one for algorithm 5 and one for algorithm 8, and the zone was signed by both. For each algorithm, I had a sequence of nine ZSKs with timing metadata set so that a key rollover would occur every 90 days for a two-year period. I had two KSKs for each algorithm: one published and active, the other published and not yet active. I processed the keys for algorithm 5 (the one to be removed) as follows using dnssec-settime: 1) For keys with a deletion date in the past, do nothing. 2) For keys currently published but deactivated, set the deletion date to earlier today (20120624). 3) For keys currently published and active, set the inactive and deletion dates to earlier today. 4) For keys currently published but not yet active, set the inactive and deletion dates to earlier today. 5) For keys with a publish date in the future, do nothing. Immediately afterwards I ran "rndc loadkeys " and for good measure "rndc sign ", although perhaps only one of these was really necessary. An AXFR immediately afterwards showed no DNSKEYs or RRSIGs remaining from algorithm 5. I think I'm good to go with this procedure. I think the proposed "resigning from scratch" procedure is less desirable since it would involve more administrative overhead and more processing by named, so I will not test that further at this point. I'll let my previously suggested enhancements to rndc stand as an alternative. Thanks. Jeff. Jeffry A. Spain Network Administrator Cincinnati Country Day School ___ 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: Seeking Advice on DNSSEC Algorithm Rollover
I propose the following addition to the Bv9ARM, and request review and comment by the experts on this list. -- 4.9.14 DNSKEY Algorithm Rollover >From time to time new digital signature algorithms with improved security are >introduced, and it may be desirable for administrators to roll over DNSKEYs to >a new algorithm, e.g. from RSASHA1 (algorithm 5 or 7) to RSASHA256 (algorithm >8). The algorithm rollover must be done with care in a stepwise fashion to >avoid breaking DNSSEC validation. As with other DNSKEY rollovers (sections 4.9.5 - 4.9.7), when the zone is of type master, an algorithm rollover can be accomplished using dynamic updates or automatic key rollovers. For zones of type slave, only automatic key rollovers are possible, but the dnssec-settime utility can be used to control the timing of such. In any case the first step is to put DNSKEYs using the new algorithm in place. You must generate the K* files for the new algorithm and put them in the zone's key directory where named can access them. Take care to set appropriate ownership and permissions on the keys. If the auto-dnssec zone option is set to maintain, named will automatically sign the zone with the new keys based on their timing metadata when the dnssec-loadkeys-interval elapses or you issue the command rndc loadkeys zone. Otherwise for zones of type master, you can use nsupdate to add the new DNSKEYs to the zone. This will cause named to use them to sign the zone. For zones of type slave, e.g. on a bump-in-the-wire inline signing server, nsupdate cannot be used. Once the zone has been signed by the new DNSKEYs, you must inform the parent zone and any trust anchor repositories of the new KSKs, e.g. you might place DS records in the parent zone through your DNS registrar's website. Before starting to remove the old algorithm from a zone, you must allow the maximum TTL on its DS records in the parent zone to expire. This will assure that any subsequent queries will retrieve the new DS records for the new algorithm. After the TTL has expired, you can remove the DS records for the old algorithm from the parent zone and any trust anchor repositories. You must then allow another maximum TTL interval to elapse so that the old DS records disappear from all resolver caches. The next step is to remove the DNSKEYs using the old algorithm from your zone. Again this can be accomplished using nsupdate to delete the old DNSKEYs (master zones only) or by automatic key rollover when auto-dnssec is set to maintain. You can cause the automatic key rollover to take place immediately by using the dnssec-settime utility to adjust the timing metadata on all key files associated with the old algorithm. There are five cases: 1) For keys with a deletion date in the past, do nothing. 2) For keys currently published but deactivated, set the deletion date to sometime in the past. 3) For keys currently published and active, set the inactive and deletion dates to sometime in the past. 4) For keys currently published but not yet active, set the inactive and deletion dates to sometime in the past. 5) For keys with a publish date in the future, do nothing. After adjusting the timing metadata, the command rndc loadkeys zone will cause named to remove the DNSKEYs and RRSIGs for the old algorithm from the zone. Note also that with the nsupdate method, removing the DNSKEYs also causes named to remove the associated RRSIGs automatically. Once you have verified that the old DNSKEYs and RRSIGs have been removed from the zone, the final step (optional) is to remove the key files for the old algorithm from the key directory. -- Jeffry A. Spain Network Administrator Cincinnati Country Day School ___ 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
