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
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
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.
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
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
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.
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