unexpected RCODE?
in [General Linux]
|
Prev: vsftpd error 500 OOPS: cannot change directory:/home/ftp
Next: retchmail error: No data found, aborting
From: ToddAndMargo on 14 Dec 2008 18:24 Hi All, I get this when I browse over to watch an episode of Psyche over on the USA network in my /var/log/messages: Dec 14 15:17:59 rn1 named[2839]: unexpected RCODE (REFUSED) resolving 'video.usanetwork.com/AAAA/IN': 192.131.228.90#53 Dec 14 15:17:59 rn1 named[2839]: unexpected RCODE (REFUSED) resolving 'video.usanetwork.com/AAAA/IN': 205.173.93.213#53 Any idea what it means? Many thanks, -T
From: Allen Kistler on 14 Dec 2008 18:47 ToddAndMargo wrote: > Hi All, > > I get this when I browse over to watch an > episode of Psyche over on the USA network in > my /var/log/messages: > > Dec 14 15:17:59 rn1 named[2839]: unexpected RCODE (REFUSED) resolving > 'video.usanetwork.com/AAAA/IN': 192.131.228.90#53 > Dec 14 15:17:59 rn1 named[2839]: unexpected RCODE (REFUSED) resolving > 'video.usanetwork.com/AAAA/IN': 205.173.93.213#53 > > Any idea what it means? AAAA are IPv6 DNS records, like A records are IPv4. Perhaps your workstation and the DNS server can't agree on whether you're using IPv6 or not.
From: Moe Trin on 15 Dec 2008 15:01 On Sun, 14 Dec 2008, in the Usenet newsgroup comp.os.linux.misc, in article <6Bg1l.1671$c35.959(a)nwrddc02.gnilink.net>, ToddAndMargo wrote: > I get this when I browse over to watch an >episode of Psyche over on the USA network in >my /var/log/messages: > >Dec 14 15:17:59 rn1 named[2839]: unexpected RCODE (REFUSED) resolving >'video.usanetwork.com/AAAA/IN': 192.131.228.90#53 >Dec 14 15:17:59 rn1 named[2839]: unexpected RCODE (REFUSED) resolving >'video.usanetwork.com/AAAA/IN': 205.173.93.213#53 1035 Domain names - implementation and specification. P.V. Mockapetris. November 1987. (Format: TXT=125626 bytes) (Obsoletes RFC0973, RFC0882, RFC0883) (Updated by RFC1101, RFC1183, RFC1348, RFC1876, RFC1982, RFC1995, RFC1996, RFC2065, RFC2136, RFC2181, RFC2137, RFC2308, RFC2535, RFC2845, RFC3425, RFC3658, RFC4033, RFC4034, RFC4035, RFC4343) (Also STD0013) (Status: STANDARD) 2136 Dynamic Updates in the Domain Name System (DNS UPDATE). P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound. April 1997. (Format: TXT=56354 bytes) (Updates RFC1035) (Updated by RFC3007, RFC4035, RFC4033, RFC4034) (Status: PROPOSED STANDARD) page 5 of RFC2136: RCODE Response code - this four bit field is undefined in requests and set in responses. The values and meanings of this field within responses are as follows: Mneumonic Value Description ------------------------------------------------------------ [...] NOTIMP 4 The name server does not support the specified Opcode. REFUSED 5 The name server refuses to perform the specified operation for policy or security reasons. That's pretty plain. Your application (most likely, but it could be a fundamental of the kernel) asked for an IPv6 address for the host video.usanetwork.com (AAAA record). Both DNS servers are not willing (or able) to provide that answer. In actual use, a NOTIMP would be more appropriate, but this is the way the guy who configured those servers set it up. >Any idea what it means? Many Linux distributions are configured to use IPv6 _if_available_ with a fall-back to IPv4. If you look at the output of /sbin/ifconfig you'll probably see lines looking _something_ like eth0 Link encap:Ethernet HWaddr 00:60:97:32:4A:6A inet addr:192.0.2.11 Bcast:192.0.2.255 Mask:255.255.255.0 inet6 addr: fe80::260:97ff:fe32:4a6a/64 Scope:Link 'inet6' refers to IPv6. The 'fe80::' address range is a LinkLocal, much like 169.254.x.y in IPv4 - it's an address your computer has pulled out of it's a$$ because a DHCP server wouldn't assign a proper address in that protocol. You don't identify the distribution, but a Red Hat derivative would control IPv6 in the file /etc/sysconfig/network with the line NETWORKING_IPV6=no The message you show came from a named process (PID 2839), so this might also be a local configuration of your name server process on host 'rn1'. Bottom line: Your system asked for an IPv6 address, and the name server (probably immediately) refused the request. Your system then asked for an IPv4 address (A record), got a valid answer, and away you go. This is not a problem, compared to a more normal response of a AAAA response and no route to that address because North America is not well covered in IPv6, _OR_ the name server _ignoring_ your IPv6 request, resulting in a 5-10 second delay while the request times out. Old guy
From: ToddAndMargo on 15 Dec 2008 16:48
Moe Trin wrote: > Bottom line: Your system asked for an IPv6 address, and the name > server (probably immediately) refused the request. Your system then > asked for an IPv4 address (A record), got a valid answer, and away > you go. This is not a problem, compared to a more normal response of > a AAAA response and no route to that address because North America is > not well covered in IPv6, _OR_ the name server _ignoring_ your IPv6 > request, resulting in a 5-10 second delay while the request times out. > > Old guy That explains it. Thank you! -T |