Re: Understanding cause of DNS format error (FORMERR)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello Gabriele,
On 6/22/12 11:22 AM, Gabriele Paggi wrote:
I'm a BIND novice and I'm trying to understand what causes my
BIND9 resolver (bind97-9.7.0-10.P2) to return an error when queried
for the A record of vlasext.partners.extranet.microsoft.com:
At Men Mice I've investigated this issue a few weeks ago for one of
our customers. At that point of time, we've seen NS records with
private addresses:
dig ns partners.extranet.microsoft.com.
; DiG 9.9.1 ns partners.extranet.microsoft.com.
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 53053
;; flags: qr rd ra; QUERY: 1, ANSWER: 18, AUTHORITY: 0, ADDITIONAL: 19
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;partners.extranet.microsoft.com. INNS
;; ANSWER SECTION:
partners.extranet.microsoft.com. 2311 IN NS
db3-ptnr-dc-01.partners.extranet.microsoft.com.
partners.extranet.microsoft.com. 2311 IN NS
tk5-ptnr-dc-02.partners.extranet.microsoft.com.
partners.extranet.microsoft.com. 2311 IN NS
by1-ptnr-dc-03.partners.extranet.microsoft.com.
partners.extranet.microsoft.com. 2311 IN NS
co2-ptnr-dc-02.partners.extranet.microsoft.com.
partners.extranet.microsoft.com. 2311 IN NS
co2-ptnr-dc-01.partners.extranet.microsoft.com.
partners.extranet.microsoft.com. 2311 IN NS
sinxtdnsz01.partners.extranet.microsoft.com.
partners.extranet.microsoft.com. 2311 IN NS
kaw-ptnr-dc-02.partners.extranet.microsoft.com.
partners.extranet.microsoft.com. 2311 IN NS
ph1-ptnr-dc-01.partners.extranet.microsoft.com.
partners.extranet.microsoft.com. 2311 IN NS
tk5-ptnr-dc-01.partners.extranet.microsoft.com.
partners.extranet.microsoft.com. 2311 IN NS
tk5-ptnr-dc-05.partners.extranet.microsoft.com.
partners.extranet.microsoft.com. 2311 IN NS
rno-ptnr-dc-01.partners.extranet.microsoft.com.
partners.extranet.microsoft.com. 2311 IN NS
tk5-ptnr-dc-03.partners.extranet.microsoft.com.
partners.extranet.microsoft.com. 2311 IN NS
sin-ptnr-dc-03.partners.extranet.microsoft.com.
partners.extranet.microsoft.com. 2311 IN NS
sin-ptnr-dc-02.partners.extranet.microsoft.com.
partners.extranet.microsoft.com. 2311 IN NS
by1-ptnr-dc-04.partners.extranet.microsoft.com.
partners.extranet.microsoft.com. 2311 IN NS
kaw-ptnr-dc-03.partners.extranet.microsoft.com.
partners.extranet.microsoft.com. 2311 IN NS
db3-ptnr-dc-02.partners.extranet.microsoft.com.
partners.extranet.microsoft.com. 2311 IN NS
ph1-ptnr-dc-02.partners.extranet.microsoft.com.
;; ADDITIONAL SECTION:
db3-ptnr-dc-01.partners.extranet.microsoft.com. 1406 IN A 10.251.138.15
tk5-ptnr-dc-02.partners.extranet.microsoft.com. 26 IN A 10.251.51.102
by1-ptnr-dc-03.partners.extranet.microsoft.com. 3505 IN A 10.251.94.15
co2-ptnr-dc-02.partners.extranet.microsoft.com. 2941 IN A 10.251.152.89
co2-ptnr-dc-01.partners.extranet.microsoft.com. 2679 IN A 10.251.152.173
sinxtdnsz01.partners.extranet.microsoft.com. 171 IN A 10.251.168.142
kaw-ptnr-dc-02.partners.extranet.microsoft.com. 1101 IN A 10.251.162.20
ph1-ptnr-dc-01.partners.extranet.microsoft.com. 1417 IN A 10.251.26.11
tk5-ptnr-dc-01.partners.extranet.microsoft.com. 2872 IN A 10.251.51.13
tk5-ptnr-dc-05.partners.extranet.microsoft.com. 137 IN A 10.251.52.143
rno-ptnr-dc-01.partners.extranet.microsoft.com. 1375 IN A 10.251.64.113
tk5-ptnr-dc-03.partners.extranet.microsoft.com. 1564 IN A 10.251.52.124
sin-ptnr-dc-03.partners.extranet.microsoft.com. 882 IN A 10.251.168.67
sin-ptnr-dc-02.partners.extranet.microsoft.com. 505 IN A 10.251.169.47
by1-ptnr-dc-04.partners.extranet.microsoft.com. 2270 IN A 10.251.94.16
kaw-ptnr-dc-03.partners.extranet.microsoft.com. 3461 IN A 10.251.162.193
db3-ptnr-dc-02.partners.extranet.microsoft.com. 1690 IN A 10.251.138.59
ph1-ptnr-dc-02.partners.extranet.microsoft.com. 3018 IN A 10.251.26.12
;; Query time: 1314 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed May 30 18:57:27 2012
;; MSG SIZE rcvd: 867
The issue seem to differ from the point in the network you are sending
the query, and if the resolving DNS server has only IPv4 or is
dual-stack (IPv4 + IPv6). It seems that the resolution is sometimes
broken, but we have not found the root cause of the issue.
This forward zone proved to be an (ugly, but working) workaround:
zone partners.extranet.microsoft.com IN {
type forward;
forwarders { 131.107.125.65;
94.245.124.49;
207.46.55.10;
65.55.31.17; };
};
We've also informed Microsoft about 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/le38ACgkQsUJ3c+pomYEwDACgit4MdoFl4rfSCcapx1NMr9cB
1bUAn1QNRM2Gw//EsLYnH1jw1g25IvFl
=hB+P
-END PGP SIGNATURE-
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
Re: Understanding cause of DNS format error (FORMERR)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Gabriele, On 6/22/12 11:22 AM, Gabriele Paggi wrote: I'm a BIND novice and I'm trying to understand what causes my BIND9 resolver (bind97-9.7.0-10.P2) to return an error when queried for the A record of vlasext.partners.extranet.microsoft.com: 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: # dig @ns1.msft.net. partners.extranet.microsoft.com ns ; DiG 9.9.1-P1 ns @ns1.msft.net. partners.extranet.microsoft.com ; (2 servers found) ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: FORMERR, id: 30679 ;; flags: qr rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;partners.extranet.microsoft.com. INNS ;; Query time: 167 msec ;; SERVER: 2a01:111:2005::1:1#53(2a01:111:2005::1:1) ;; WHEN: Sat Jun 23 10:47:33 2012 ;; MSG SIZE rcvd: 60 If some other members of this mailing list also see the same FORMERR (I'm seeing it over IPv4+IPv6), that is is very likely a firewall or middlebox on the Microsoft side. 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/lhEsACgkQsUJ3c+pomYE8RwCgldVhiIiwuavJGy0VEQAbek5M d7sAoKg1ny9dN6UMhuXyF1a6diylGyzz =+PcU -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
Seeking Advice on DNSSEC Algorithm Rollover
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. The zones on my server (BIND 9.9.1-P1) are set up as slaves for inline signing. Unsigned zone data is received from a stealth master via inbound zone transfer. Each zone is configured for auto-dnssec maintain and inline-signing yes. A series of ZSKs and KSKs are stored in key directories by zone with timing metadata set to keep two ZSKs and KSKs published and one active. There is no update-policy statement in place. Both the unsigned and signed zone files are in raw format by default. The dnssec-loadkeys-interval is not specified and so defaults to 60 minutes. First of all, the procedure for adding the new algorithm 8 seems simple, and I already did this successfully: a) Create the required algorithm-8 ZSKs and KSKs and place them in the key directories, carefully setting ownership and permissions. b) rndc sign zone for all zones or wait for dnssec-loadkeys-interval to elapse. c) After verifying that the new DNSKEYs, RRSIGs, and NSECs are in place, publish the required algorithm-8 DS records in the parent zones. The procedure for removing the old algorithm 7 keys seems trickier. I believe nsupdate will be required, and so update-policy local will need to be added to the configuration of each zone followed by rndc reload. I think the option dnssec-secure-to-insecure yes may also need to be configured for this to work: a) Remove the algorithm-7 DS records from the parent zones. b) Wait for the maximum TTL to expire. From inspection this varies among gTLDs and may be as long as 24 hours. c) Remove all the algorithm 7 keys from the key directories. d) Using nsupdate, delete all of the algorithm 7 DNSKEYs from each zone. All algorithm-7 RRSIGs and NSECs should be automatically removed when the updates are sent. I am concerned that step c) may cause a problem if named decides to carry out any signing activities prior to the completion of step d). One could examine all the RRSIGs and confirm based on sig-validity-interval that no signing activity is immanent, but that seems tedious. One could also temporarily change auto-dnssec from maintain to allow, but that also seems cumbersome if there are lots of zones. Perhaps another rndc command could be developed to help with this. For example, rndc pause-signing zone might disable signing activities temporarily until a subsequent rndc sign command was sent, or as a safety valve, until the next dnssec-loadkeys-interval elapsed. The dnssec-update-mode option seems to incorporate this idea, but it must be statically configured, and is said to work only for master zones (as opposed to the inline-signed slave zones that I have). I would be grateful for your additional thoughts on this. 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: Understanding cause of DNS format error (FORMERR)
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). stanislao:~ gpaggi$ dig A @62.179.104.196 vlasext.partners.extranet.microsoft.com +short 70.42.230.20 stanislao:~ gpaggi$ dig A @8.8.8.8 vlasext.partners.extranet.microsoft.com +short 70.42.230.20 I'm trying to understand if this behavior is specific to the BIND release that I'm running (should be the latest available on CentOS 5) and what's triggering it. Increasing debug logging to 90 doesn't tell me what's wrong with the reply BIND gets from the Microsoft DNS. # dig @ns1.msft.net. partners.extranet.microsoft.com ns [...] If some other members of this mailing list also see the same FORMERR (I'm seeing it over IPv4+IPv6), that is is very likely a firewall or middlebox on the Microsoft side. I do get indeed a reply from my home connection: stanislao:~ gpaggi$ dig @ns1.msft.net. partners.extranet.microsoft.com ns ; DiG 9.6-ESV-R4-P3 @ns1.msft.net. partners.extranet.microsoft.com ns ; (1 server found) ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 37303 ;; flags: qr rd; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 4 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;partners.extranet.microsoft.com. INNS ;; ANSWER SECTION: partners.extranet.microsoft.com. 3600 IN NSdns13.one.microsoft.com. partners.extranet.microsoft.com. 3600 IN NSdns11.one.microsoft.com. partners.extranet.microsoft.com. 3600 IN NSdns12.one.microsoft.com. partners.extranet.microsoft.com. 3600 IN NSdns10.one.microsoft.com. ;; ADDITIONAL SECTION: dns13.one.microsoft.com. 3600INA65.55.31.17 dns11.one.microsoft.com. 3600INA94.245.124.49 dns12.one.microsoft.com. 3600INA207.46.55.10 dns10.one.microsoft.com. 3600INA131.107.125.65 ;; Query time: 201 msec ;; SERVER: 65.55.37.62#53(65.55.37.62) ;; WHEN: Sun Jun 24 05:51:37 2012 ;; MSG SIZE rcvd: 197 Gabriele PS. Carsten, apologizes for the double message. ___ 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)
Hello Carsten, At Men Mice I've investigated this issue a few weeks ago for one of our customers. At that point of time, we've seen NS records with private addresses: That's interesting but it still doesn't explain why BIND reports a format error in the reply it receives. The reply is nonsense but it's legit and BIND should just return it. Am I wrong? Beside that, I've been constantly getting a FORMERR reply for a week now. The issue seem to differ from the point in the network you are sending the query, and if the resolving DNS server has only IPv4 or is dual-stack (IPv4 + IPv6). It seems that the resolution is sometimes broken, but we have not found the root cause of the issue. I'm running with only IPv4. May I ask you which version of BIND are you running? Jeffry is not able to reproduce the issue using BIND 9.9.1-P1 and I might consider an upgrade. We've also informed Microsoft about the issue. I know what the answer is but I'll ask anyway: did you ever get a reply / acknowledgement from them? Thanks! Gabriele ___ 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)
Hello Jeffry, FWIW I'm not able to reproduce this using a BIND 9.9.1-P1 recursive resolver. On this system dig @localhost vlasext.partners.extranet.microsoft.com a returns the answer 70.42.230.20 and identifies dns11.one.microsoft.com (94.245.124.49) as one of four authoritative servers. dig @94.245.124.49 vlasext.partners.extranet.microsoft.com a also returns the answer 70.42.230.20, but no authority or additional records (except EDNS UDP 4000), and with no AA flag set. On the contrary querying one of my own authoritative servers, also running BIND 9.9.1-P1, for a record for which it is authoritative (dig @ns2.countryday.net countryday.net a) does return the answer along with authority and additional records for the name servers and does have the AA flag set. Finally querying one of my internal Microsoft DNS servers (Windows Server 2008 R2 SP1) for a record for which it is authoritative gives me a correct answer, no authority or additional records (except EDNS UDP 4000), but does have the AA flag set. Thanks. At least I know an upgrade would fix the issue although I still don't know what and where the problem is (Microsoft DNS reply? BIND?). 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. 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. I kind of assumed Microsoft would have been running a Windows DNS for their domains ;-) Gabriele ___ 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
