Tickets - lack of rDNS on tunnel causing big problems :: SixXS

Ticket ID: SIXXS #768768
Ticket Status: User

PoP: (not applicable)

lack of rDNS on tunnel causing big problems

Shadow Hawkins on Sunday, 20 July 2008 23:34:18

OK, here's the deal. I have a single host connected to a tunnel. It runs an LDAP server which uses GSSAPI authentication with the krb5 mechanism. Everything was working fine until I added the host's AAAA record into DNS. Now here's what I get in the logs when the client tries to authenticate: ldapsearch: GSSAPI Error: Miscellaneous failure (see text) (Server (krbtgt/EWR-01.US.SIXXS.NET@MYREALM) unknown) "MYREALM" is actually, of course, my realm. If you know Kerberos then you see that that's an attempt for what's known as "cross-realm authentication". That means the client is trying to get tickets for EWR-01.US.SIXXS.NET. Which is not my realm. The client does gethost(getaddr(hostname)) before determining which realm to contact. This is actually CORRECT Kerberos behaviour to avoid spoofed IPs. However, it's unfixable unless I have the capability to create a real rDNS entry for my tunnel endpoint (or I request, allocate, and waste all but one address of a new subnet just to get rDNS capabilities). I cannot restrict the LDAP server to listening on IPv4 addresses only, because then IPv6-enabled clients find its AAAA and say it's down when it doesn't respond on v6. So I'm in a real pickle. Any help that you guys could offer would be appreciated. This seems like a really good reason to allow changing the rDNS of tunnel endpoints...

State change: user Locked

Jeroen Massar SixXS Staff

on Monday, 21 July 2008 09:35:50

The state of this ticket has been changed to user

lack of rDNS on tunnel causing big problems

Jeroen Massar SixXS Staff

on Monday, 21 July 2008 09:42:55

Tunnel infrastructure are transfer networks between you and the PoP. The reverses assigned there are not changeable. Your quick solutions: - Don't stick the AAAA of the tunnel endpoint in DNS used for this purpose. - Modify /etc/hosts to reflect whatever you want (eg 2001:db8::1 bla.example.com) What I find rather strange in this story is that you are setting up an LDAP server on a tunnel endpoint, thus remote from the clients. Are you not at all afraid that the tunnel might break and then cause time-outs and all kinds of other issues? Having an on-site LDAP server, and thus having a /48 for that site, makes a lot more sense. Can you detail your network 'design'?

lack of rDNS on tunnel causing big problems

Shadow Hawkins on Monday, 21 July 2008 16:23:22

I do have an on-site LDAP server. This one is a "hot spare" replica for geographically-distributed fault tolerance. The host it's on just happens to have an IPv6 address. Queries only hit this server in the event the main one is down. The LDAP data stored there is not what you're thinking of, user accounts and home directories and so forth - it's information more like PGP keys and organizational info. Stuff that needs to be known but isn't queried constantly. I suppose I could give the host a second public IP address just for the LDAP server and then make sure THAT one has no AAAA record. Or I could do the tunnel allocation. What I suppose I'll actually do is create an entry in krb5.conf that maps the domain .ewr-01.us.sixxs.net to my realm. Then hosts won't attempt cross-realm auth. It's just a shame that has to be done because all other configuration is centralized through DNS and it seems a shame to have to distribute a file to clients.

lack of rDNS on tunnel causing big problems

Jeroen Massar SixXS Staff

on Monday, 21 July 2008 17:18:22

That explanation makes a bit more sense on how your setup works, which seems logical. Just request a /48 for that location and use an IP from that range, which is the proposal you where going to use for IPv4. I do hope you employ DNSSEC, otherwise there is a big possibility to wreck your setup with ease due to various flaws in DNS. Another note is on something how I tend to setup hosts: - EUI-64 address is used for management - service address is assigned per service and actually announced per OSPF/ISIS towards the network, that way if the host/service fails the route can be taken away and another can take over and you can easily add more capacity to a service by just adding hosts and maybe doing loadbalancing, at least per location, or by sticking the device behind a loadbalancer, which uses the same anycast trick again. For IPv4 you could do similar things using IP aliases.

Please note Posting is only allowed when you are logged in.