Hallo,
ich habe im VPN Client als "DNS Domains to be resvolved in the tunnel" "*" eingestellt, trotzdem werden unqualifizierte Host Namen nicht aufgelöst, als DNS Server werden 193.254.160.1 und 10.74.83.22 verwendet (T-Mobile).
Wenn ich den DNS Server für NSLOOKUP auf den LANCOM 7100 stelle wird der Request natürlich in den Tunnel geschickt, ich erhalte allerdings die beiden unteren Meldungen (DNS Server ist ein 4006), das scheint die Default Domain nicht richtig zu funktionieren.
Mit voll qualifizierten Hostnamen funktioniert alles ohne Probleme, ebenfalls im Lokalen LAN.
Danke
Henri
nslookup
> set d2
> db2
addlookup()
make_empty_lookup()
looking up db2
start_lookup()
setup_lookup(0x7f908084a408)
resetting lookup counter.
cloning server list
clone_server_list()
make_server(193.254.160.1)
make_server(10.74.83.22)
using root origin
recursive query
add_question()
starting to render the message
done rendering
create query 0x10a415de8 linked to lookup 0x7f908084a408
create query 0x10a41b008 linked to lookup 0x7f908084a408
do_lookup()
send_udp(0x10a415de8)
bringup_timer()
have local timeout of 1
working on lookup 0x7f908084a408, query 0x10a415de8
sockcount=1
recving with lookup=0x7f908084a408, query=0x10a415de8, sock=0x10a41c000
recvcount=1
sending a request
lock_lookup /SourceCache/bind9/bind9-42/bind9/bin/dig/dighost.c:2301
success
send_done()
sendcount=0
check_if_done()
list empty
unlock_lookup /SourceCache/bind9/bind9-42/bind9/bin/dig/dighost.c:2330
connect_timeout()
lock_lookup /SourceCache/bind9/bind9-42/bind9/bin/dig/dighost.c:2580
success
trying next server...
send_udp(0x10a41b008)
bringup_timer()
have local timeout of 5
working on lookup 0x7f908084a408, query 0x10a41b008
sockcount=2
recving with lookup=0x7f908084a408, query=0x10a41b008, sock=0x10a41c210
recvcount=2
sending a request
unlock_lookup /SourceCache/bind9/bind9-42/bind9/bin/dig/dighost.c:2599
lock_lookup /SourceCache/bind9/bind9-42/bind9/bin/dig/dighost.c:2301
success
send_done()
sendcount=0
check_if_done()
list empty
unlock_lookup /SourceCache/bind9/bind9-42/bind9/bin/dig/dighost.c:2330
recv_done()
lock_lookup /SourceCache/bind9/bind9-42/bind9/bin/dig/dighost.c:3030
success
recvcount=1
lookup=0x7f908084a408, query=0x10a41b008
before parse starts
;; Got recursion not available from 10.74.83.22, trying next server
clear_query(0x10a41b008)
sockcount=1
check_next_lookup(0x7f908084a408)
still have a worker
unlock_lookup /SourceCache/bind9/bind9-42/bind9/bin/dig/dighost.c:3299
connect_timeout()
lock_lookup /SourceCache/bind9/bind9-42/bind9/bin/dig/dighost.c:2580
success
resending UDP request to first server
send_udp(0x10a415de8)
bringup_timer()
have local timeout of 5
working on lookup 0x7f908084a408, query 0x10a415de8
sending a request
unlock_lookup /SourceCache/bind9/bind9-42/bind9/bin/dig/dighost.c:2625
lock_lookup /SourceCache/bind9/bind9-42/bind9/bin/dig/dighost.c:2301
success
send_done()
sendcount=0
check_if_done()
list empty
unlock_lookup /SourceCache/bind9/bind9-42/bind9/bin/dig/dighost.c:2330
connect_timeout()
lock_lookup /SourceCache/bind9/bind9-42/bind9/bin/dig/dighost.c:2580
success
resending UDP request to first server
send_udp(0x10a415de8)
bringup_timer()
have local timeout of 5
working on lookup 0x7f908084a408, query 0x10a415de8
sending a request
unlock_lookup /SourceCache/bind9/bind9-42/bind9/bin/dig/dighost.c:2625
lock_lookup /SourceCache/bind9/bind9-42/bind9/bin/dig/dighost.c:2301
success
send_done()
sendcount=0
check_if_done()
list empty
unlock_lookup /SourceCache/bind9/bind9-42/bind9/bin/dig/dighost.c:2330
connect_timeout()
lock_lookup /SourceCache/bind9/bind9-42/bind9/bin/dig/dighost.c:2580
success
;; connection timed out; no servers could be reached
cancel_lookup()
check_if_done()
list empty
check_next_lookup(0x7f908084a408)
still have a worker
unlock_lookup /SourceCache/bind9/bind9-42/bind9/bin/dig/dighost.c:2625
recv_done()
lock_lookup /SourceCache/bind9/bind9-42/bind9/bin/dig/dighost.c:3030
success
recvcount=0
lookup=0x7f908084a408, query=0x10a415de8
no longer pending. Got operation canceled
clear_query(0x10a415de8)
sockcount=0
check_next_lookup(0x7f908084a408)
try_clear_lookup(0x7f908084a408)
destroy
freeing server 0x7f908084ba08 belonging to 0x7f908084a408
freeing server 0x7f908084c408 belonging to 0x7f908084a408
start_lookup()
check_if_done()
list empty
shutting down
dighost_shutdown()
unlock_lookup /SourceCache/bind9/bind9-42/bind9/bin/dig/dighost.c:3057
[DNS] 2011/09/14 05:11:05,980
DNS Rx (AIR): Src-IP x.x.x.x
Query Request: STD A for db2
Not found in local DNS database => forward to next server
NameQuery: Forward to locally configured DNS server
[DNS] 2011/09/14 05:11:06,200
DNS Rx (INTERNET): Src-IP x.x.x.x
Query Response:
Error: name/domain not found
Questions (1):
STD A db2
Unqualifizierter DNS Host Namen bei AVC 2.02 Mac
Moderator: Lancom-Systems Moderatoren
Hi Henri
damit unqualifizierte Namen funktionieren, muß das LANCOM den Namen kennen - aber es kennt den Namen einfach nicht und leitet die Anfrage daher an den nächsten Server weiter. Und der steht offenbar im Internet und kann daher natürlich mit unqualifizierten Namen nichts anfangen:
Wenn der Rechner "db2" im lokalen Netz des LANCOMs steht und sich entweder über DHCP eine Adresse besorgt, oder NetBIOS spicht, dann kannst du im DNS-Server die Nutzung der DHCP- und/oder NetBIOS-Informationen für die Namensauflösung aktivieren (TCP/IP -> DNS -> Adressen von DHCP-Clients auflösen / Namen von NetBIOS-Stationen auflösen)
BTW: das ist im Default aktiv, und wenn es bei dir nicht funktioniert, dann hast du das explizit abgeschaltet...
Gruß
Backlsash
damit unqualifizierte Namen funktionieren, muß das LANCOM den Namen kennen - aber es kennt den Namen einfach nicht und leitet die Anfrage daher an den nächsten Server weiter. Und der steht offenbar im Internet und kann daher natürlich mit unqualifizierten Namen nichts anfangen:
Wenn der DNS-Server des LANCOMs eine Anfrage erhält, dann hängt er bei der Weiterleitung seine eigene Domain natürlich *nicht* an - wieso sollte er auch...[DNS] 2011/09/14 05:11:05,980
DNS Rx (AIR): Src-IP x.x.x.x
Query Request: STD A for db2
Not found in local DNS database => forward to next server
NameQuery: Forward to locally configured DNS server
[DNS] 2011/09/14 05:11:06,200
DNS Rx (INTERNET): Src-IP x.x.x.x
Query Response:
Error: name/domain not found
Questions (1):
STD A db2
Wenn der Rechner "db2" im lokalen Netz des LANCOMs steht und sich entweder über DHCP eine Adresse besorgt, oder NetBIOS spicht, dann kannst du im DNS-Server die Nutzung der DHCP- und/oder NetBIOS-Informationen für die Namensauflösung aktivieren (TCP/IP -> DNS -> Adressen von DHCP-Clients auflösen / Namen von NetBIOS-Stationen auflösen)
BTW: das ist im Default aktiv, und wenn es bei dir nicht funktioniert, dann hast du das explizit abgeschaltet...
Gruß
Backlsash
Hallo \,
danke. Aber ich hatte ein Ticket für die Trial Version von NCP aufgemacht und geantwortet bekommen, dass diese Funktion bisher nicht implementiert sein. Scheint man bei Build 14 nachgeholt zu haben, Ihr hat leider noch immer Build 12 und mein Lancom Ticket ist im Sande verlaufen. Ich habe recht lange gesucht, daher habe ich die Antwort hier gepostet damit andere nicht ähnlich lange suchen müssen.
Viele Grüße
Henri
1. Changes in Version 2.02 Build 14
DNS Domains to be resolved in the Tunnel
Regardless of whether or not Split Tunneling is in use, which DNS queries must be routed through the tunnel can be defined in the configuration field “IPsec Address Allocation”; enter the DNS name required under “DNS Domains to be resolved in the Tunnel”.
In a newly created VPN profile the default entry in “DNS Domains to be resolved in the Tunnel” is blank, i.e. the default is that all DNS queries are routed outside the tunnel to the DNS server that has been allocated in the Internet (by the provider).
danke. Aber ich hatte ein Ticket für die Trial Version von NCP aufgemacht und geantwortet bekommen, dass diese Funktion bisher nicht implementiert sein. Scheint man bei Build 14 nachgeholt zu haben, Ihr hat leider noch immer Build 12 und mein Lancom Ticket ist im Sande verlaufen. Ich habe recht lange gesucht, daher habe ich die Antwort hier gepostet damit andere nicht ähnlich lange suchen müssen.
Viele Grüße
Henri
1. Changes in Version 2.02 Build 14
DNS Domains to be resolved in the Tunnel
Regardless of whether or not Split Tunneling is in use, which DNS queries must be routed through the tunnel can be defined in the configuration field “IPsec Address Allocation”; enter the DNS name required under “DNS Domains to be resolved in the Tunnel”.
In a newly created VPN profile the default entry in “DNS Domains to be resolved in the Tunnel” is blank, i.e. the default is that all DNS queries are routed outside the tunnel to the DNS server that has been allocated in the Internet (by the provider).