Dear HP: If your not going to support IPv6 can you at least not return SRVFAIL when asked for an AAAA record: root@spoons:/etc/mail # dig AAAA onramp01.hpeprint.com ; <<>> DiG 9.8.3-P4 <<>> AAAA onramp01.hpeprint.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 61583 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;onramp01.hpeprint.com. IN AAAA And what genius thought that emailing documents to printers was a good idea in the first place? Nothing like taking graphics, turning it into 7 bit text, and sending it through a system never intended for the purpose. Supporting luser email is a big enough pain in the arse, now I have to deal with your idiotic printers as well? Gee thanks! Mark
On Sat, May 3, 2014 at 6:27 AM, Mark Radabaugh <mark@amplex.net> wrote:
Dear HP:
If your not going to support IPv6 can you at least not return SRVFAIL when asked for an AAAA record:
They aren't. Your resolver is - or at least, that's what it looks like for me. Sending an AAAA query to their nameservers times out for me - no response at all. Sending the same query through certain resolvers (eg, Google) seems to result in the timeout being turned into a SERVFAIL. $ dig AAAA onramp01.hpeprint.com ; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> AAAA onramp01.hpeprint.com ;; global options: +cmd ;; connection timed out; no servers could be reached Same via Google : $ dig AAAA onramp01.hpeprint.com @8.8.8.8 ; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> AAAA onramp01.hpeprint.com @8.8.8.8 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 26319 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 Scott
Either way - it breaks Sendmail, some versions of Exchange, and possibly other MTA's. The proper answer to a non-existent AAAA record is NOERROR, with ANSWER 0. Hanging or refusing to answer doesn't result in another attempt to look for an A record since the name server failed to respond to a valid query. Given that the whole point of the domain is to enable email printing, HP isn't making it easy. Mark On 5/3/14, 4:18 PM, Scott Howard wrote:
On Sat, May 3, 2014 at 6:27 AM, Mark Radabaugh <mark@amplex.net <mailto:mark@amplex.net>> wrote:
Dear HP:
If your not going to support IPv6 can you at least not return SRVFAIL when asked for an AAAA record:
They aren't. Your resolver is - or at least, that's what it looks like for me.
Sending an AAAA query to their nameservers times out for me - no response at all. Sending the same query through certain resolvers (eg, Google) seems to result in the timeout being turned into a SERVFAIL.
$ dig AAAA onramp01.hpeprint.com <http://onramp01.hpeprint.com>
; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> AAAA onramp01.hpeprint.com <http://onramp01.hpeprint.com> ;; global options: +cmd ;; connection timed out; no servers could be reached
Same via Google : $ dig AAAA onramp01.hpeprint.com <http://onramp01.hpeprint.com> @8.8.8.8 <http://8.8.8.8>
; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> AAAA onramp01.hpeprint.com <http://onramp01.hpeprint.com> @8.8.8.8 <http://8.8.8.8> ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 26319 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
Scott
-- Mark Radabaugh Amplex mark@amplex.net 419.837.5015 x 1021
On Sat, May 3, 2014 at 10:02 PM, Mark Radabaugh <mark@amplex.net> wrote:
Either way - it breaks Sendmail, some versions of Exchange, and possibly other MTA's. The proper answer to a non-existent AAAA record is NOERROR, with ANSWER 0.
if I ask ns1/2/3/4/5/6.hp.com directly for AAAA for onramp01.hpeprint.com.: ; <<>> DiG 9.8.1-P1 <<>> AAAA onramp01.hpeprint.com. @ns6.hp.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30318 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 6 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;onramp01.hpeprint.com. IN AAAA (I get the same result for all ns hosts) if I ask my local bind (ubuntu package == 1:9.8.1.dfsg.P) though I get: $ dig AAAA onramp01.hpeprint.com @localhost ; <<>> DiG 9.8.1-P1 <<>> AAAA onramp01.hpeprint.com @localhost ;; global options: +cmd ;; connection timed out; no servers could be reached That's a bit weird and frustrating.
Hanging or refusing to answer doesn't result in another attempt to look for an A record since the name server failed to respond to a valid query. Given that the whole point of the domain is to enable email printing, HP isn't making it easy.
scott's request LOOKS like a request to 'some resolver' (not directly to them, perhaps his local bind instance? I wonder why 8.8.8.8 returns srvfail? I think one of the google-public-dns people reads nanog, perhaps he knows? (or could fix this which seems to be a bug, to me at least) -chris
Once upon a time, Christopher Morrow <morrowc.lists@gmail.com> said:
if I ask ns1/2/3/4/5/6.hp.com directly for AAAA for onramp01.hpeprint.com.:
; <<>> DiG 9.8.1-P1 <<>> AAAA onramp01.hpeprint.com. @ns6.hp.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30318 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 6 ;; WARNING: recursion requested but not available
;; QUESTION SECTION: ;onramp01.hpeprint.com. IN AAAA
You left out the authority section that refers you to the correct DNS servers - ns[1-6].hp.com are not it. They delegate to another set of HP servers, which all time out (as stated by the OP) when asked for AAAA. Oddly, it seems to be specific to AAAA; any other type request I send comes back NOERROR correctly. It is like somebody tried to handle AAAA "special" and screwed it up. -- Chris Adams <cma@cmadams.net>
On Sat, May 3, 2014 at 8:13 PM, Chris Adams <cma@cmadams.net> wrote:
You left out the authority section that refers you to the correct DNS servers - ns[1-6].hp.com are not it. They delegate to another set of HP servers, which all time out (as stated by the OP) when asked for AAAA.
Actually the OP said that it returned SERVFAIL, which the HP servers don't, but Googles public DNS server (and potentially others) does.
Oddly, it seems to be specific to AAAA; any other type request I send comes back NOERROR correctly. It is like somebody tried to handle AAAA "special" and screwed it up.
This isn't new. RFC 4074 from 2005 covers this exact issue. From memory, this is/was the default behavior for DJBDNS. Scott
On Sat, May 3, 2014 at 11:13 PM, Chris Adams <cma@cmadams.net> wrote:
Once upon a time, Christopher Morrow <morrowc.lists@gmail.com> said:
if I ask ns1/2/3/4/5/6.hp.com directly for AAAA for onramp01.hpeprint.com.:
; <<>> DiG 9.8.1-P1 <<>> AAAA onramp01.hpeprint.com. @ns6.hp.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30318 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 6 ;; WARNING: recursion requested but not available
;; QUESTION SECTION: ;onramp01.hpeprint.com. IN AAAA
You left out the authority section that refers you to the correct DNS
darned it :( yes.
servers - ns[1-6].hp.com are not it. They delegate to another set of HP servers, which all time out (as stated by the OP) when asked for AAAA.
yup :(
Oddly, it seems to be specific to AAAA; any other type request I send comes back NOERROR correctly. It is like somebody tried to handle AAAA "special" and screwed it up.
I remember nytimes doing something like this for a while, I believe they said their GSLB was just not happy doing AAAA, or if not configured would display similar behaviour. -chris
On 5/3/2014 9:10 PM, Christopher Morrow wrote:
On Sat, May 3, 2014 at 11:13 PM, Chris Adams <cma@cmadams.net> wrote:
Once upon a time, Christopher Morrow <morrowc.lists@gmail.com> said: ... Oddly, it seems to be specific to AAAA; any other type request I send comes back NOERROR correctly. It is like somebody tried to handle AAAA "special" and screwed it up.
I remember nytimes doing something like this for a while, I believe they said their GSLB was just not happy doing AAAA, or if not configured would display similar behaviour.
Thanks for reporting this. I passed it on to the corp-IT people and the issue appears to be fixed. The problem was that someone forgot to override the F5 default of *NOT* enabling a NODATA/NOERROR response for AAAA queries. I have no idea why an opt-in would be required for proper interoperability with RFC 1034 from 1987. Then again, I have zero experience with operating a load balancer appliance. ------ Andris
In message <5367FDCE.6090101@hpl.hp.com>, Andris Kalnozols writes:
On 5/3/2014 9:10 PM, Christopher Morrow wrote:
On Sat, May 3, 2014 at 11:13 PM, Chris Adams <cma@cmadams.net> wrote:
Once upon a time, Christopher Morrow <morrowc.lists@gmail.com> said: ... Oddly, it seems to be specific to AAAA; any other type request I send comes back NOERROR correctly. It is like somebody tried to handle AAAA "special" and screwed it up.
I remember nytimes doing something like this for a while, I believe they said their GSLB was just not happy doing AAAA, or if not configured would display similar behaviour.
Thanks for reporting this. I passed it on to the corp-IT people and the issue appears to be fixed. The problem was that someone forgot to override the F5 default of *NOT* enabling a NODATA/NOERROR response for AAAA queries. I have no idea why an opt-in would be required for proper interoperability with RFC 1034 from 1987. Then again, I have zero experience with operating a load balancer appliance.
------ Andris
Can you please log a bug report with F5 about the defaults. It should answer all queries unless a backing nameserver has been configured. It should also sanity check the negative responses to ensure that they have the correct SOA record from the backing server but that is another issue. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
participants (6)
-
Andris Kalnozols -
Chris Adams -
Christopher Morrow -
Mark Andrews -
Mark Radabaugh -
Scott Howard