[Apache2/nginx] Wordpress updates/installaties en ipv6

[idef1x]

Ik snap het even niet meer:

- ik heb een ubuntu server (12.04) met zowel apache2 als nginx erop (niet beiden gelijk actief uiteraard).
- tevens wordpress 3.5.2 erop
- server heeft ook ipv6 actief (met global IP)

Wanneer ik nu met apache2 actief in het wordpress dashboard een theme of plugin wil installeren/updaten, dan probeerd apache2 het kennelijk via ipv6, maar het address van wordpress.org (heeft geen ipv6 zo te zien) lijkt dan naar mijn locale server te resolven en dus kan het bestand niet worden gevonden.
Ik zie namelijk zoiets in mijn lokale apache logs:

code:

2a02:xxxx:xxxx:xxxx:xxxx - - [13/Jul/2013:12:46:43 +0200] "GET /themes/download.....

Wanneer ik nu hetzelfde doe met nginx actief (en apache niet actief) dan werkt het wel naar behoren.

Doe ik het nog eens met apache2 actief en verwijder mijn ipv6 address op de server, dan doet apache2 het ook goed??

Iemand enig idee waar ik moet zoeken om het onder apache2 MET ipv6 actief werkend te krijgen?

[CAPSLOCK2000]

Volgens mij zoek je het in de verkeerde hoek. Apache en Nginx doen zelf niks, die reageren alleen maar. Het is PHP die het werk doet en dus blijkbaar besluit om naar je lokale IP te verbinden.
Als ik me goed herinner luistert nginx standaard niet naar IPv6 en Apache wel. Misschien verklaart dat het verschil in gedrag.

Nu is de vraag nog waarom er een verbinding met localhost wordt opgezet. Hoe zit het met DNS? Draai je zelf een DNS-server of gebruik je een externe? Geeft die misschien een verkeerd antwoord voor IPv6?

[idef1x]

Dank voor de hint. Inderdaad nginx start niet standaard op ipv6...Nog een reden om maar bij apache te blijven
Ook nginx doet het daarna inderdaad niet meer, dus okee terug naar welk php script het dan doet ....
Zal wel iets met curl te maken hebben, want die blijkt het ook op de commandline niet te kunnen vinden...

[Ultraman]

idef1x schreef op zaterdag 13 juli 2013 @ 17:30:
Dank voor de hint. Inderdaad nginx start niet standaard op ipv6...Nog een reden om maar bij apache te blijven

offtopic:
nginx 1.2.x doet standaard inderdaad geen IPv6 op de wildcard, maar het kan wel. Geen idee of dat in de huidige 1.4.x branch veranderd is... maar dat maakt nu even niet uit.
Ik heb hier nginx dual-stack (IPv4 en IPv6) draaien en dat werkt prima.
Kan het zijn dat het in je configuratie zit?
Voor nginx:

server {
listen [::]:80 default_server ipv6only=on rcvbuf=1k sndbuf=128k backlog=128;
listen 80 rcvbuf=1k sndbuf=128k backlog=128;

root /.../htdocs
...
}

Ik heb het aan de praat gekregen met twee listen statements in hetzelfde server block, waarvan de eerste voor IPv6 en de tweede voor IPv4.

[ Voor 45% gewijzigd door Ultraman op 13-07-2013 23:51 ]

[Osiris]

Als een HTTP-client opeens naar je eigen bak gaat connecten, terwijl je een hostname opgeeft, dan zit er (als ik ff logisch nadenk) eerder iets verkeerd in je DNS-resolving?

[idef1x]

DNS resolving werkt volgens mij prima. Als ik een "host wordpress.org" doe, krijg ik toch echt alleen ipv4 adressen terug:

code:

host wordpress.org
wordpress.org has address 66.155.40.250
wordpress.org has address 66.155.40.249
wordpress.org mail is handled by 10 mail.wordpress.org.

Hmmm met een ping6 wordpress.org kom ik ook bij mezelf uit....Maar eens een packet capture gestart en zie nu dat ie vreemd genoeg mijn eigen domain toevoegd aan de request:
wordpress.org.sjomar.eu en aangezien ik een wildcard voor mijn domain heb.....
Okee dus nu uitzoeken waarom ie dat doet en waar dat aan te passen....in de /etc/resolv.conf staan alleen de dns servers, dus ergens anders moet dat vast staan iets van search domain of append domain..... (ook niet in /etc/network/interfaces overigens)
Blijft raar dat ie dat op ipv4 dan niet doet..

edit: even de wildcard voor mijn domain op ipv6 verwijderd en dan werkt het wel goed...Dus blijft de vraag over waarom op ipv6 mijn eigen domain geappend wordt (indien ipv6) en waarom dat op ipv4 niet gebeurd...beetje vaag

[ Voor 13% gewijzigd door idef1x op 13-07-2013 19:25 . Reden: wildcard voor domain verhaal toegevoegd. ]

[Osiris]

search Search list for host-name lookup.
       The  search  list  is  normally determined from the local domain name;
       by default, it contains only the local domain name.  This may be
       changed by listing the  desired  domain  search  path following  the
       search keyword with spaces or tabs separating the names. Resolver
       queries having fewer than ndots dots (default is 1) in them will be
       attempted using each component of the search  path in turn until a
       match is found.

options
       Options allows certain internal resolver variables to be modified.
       The syntax is

              options option ...

       where option is one of the following:

       ndots:n
              sets a threshold for the  number  of  dots  which  must  appear
              in  a  name  given  to res_query(3)  (see  resolver(3))  before
              an initial absolute query will be made.  The default for n is 1,
              meaning that if there are any dots in a  name,  the  name  will
              be tried  first  as  an  absolute name before any search list
              elements are appended to it. The value for this option is
              silently capped to 15.

Misschien is jouw default ndots wel anders? Of toch iets met IPv6 idd.. Kan 't zo snel niet vinden via Google TBH.

[idef1x]

ndots is het denk ik ook niet. Via een andere site (http://serverfault.com/qu...nf-slow-lookups-on-ubuntu en dan de antwoorden), heb ik de resolv.conf eens aangepast en een search path naar een ander domain gezet en toen werkte het ook. Waarom het dan bij ipv4 zonder dat search path wel werkt blijft nog even een mysterie voor me, maar okee, ik denk dat ik dan maar de wildcard voor mijn domein weghaal, dat lijkt me netter dan er een vaag search path in te zetten.

[Hero of Time]

Je hebt *.jouwdomein.ext in je hosts file staan? Heb je hier ook een IPv6 adres aan hangen? Zoja, dan komt dit hele probleem omdat je geen IPv6 DNS servers in je resolv.conf hebt. IPv4 heeft wel wat om mee te resolven, IPv6 niet en pakt dan je hosts bestand.

[Osiris]

Euhm, huh?

Je kunt probleemloos IPv6-adressen resolven via IPv4 DNS-servers hoor? Dat staat compleet los van elkaar..

[Hero of Time]

Osiris schreef op zondag 14 juli 2013 @ 11:59:
Euhm, huh?

Je kunt probleemloos IPv6-adressen resolven via IPv4 DNS-servers hoor? Dat staat compleet los van elkaar..

Dat weet ik, maar als Apache of andere alles via IPv6 wil doen, heb je 't wel nodig, anders faalt 't.

[Osiris]

'k Vind het nog steeds verre van plausibel. De TS stelt nergens dat Apache IPv6-only is en dan daarbij zou het resolven, neem ik aan, altijd nog via het OS zelf gaan, wat sowieso niet IPv6-only is, dus dan maakt het toch niet uit of er wel of geen IPv6-DNS-server in resolv.conf staat?

[CAPSLOCK2000]

Hero of Time schreef op zondag 14 juli 2013 @ 11:50:
Je hebt *.jouwdomein.ext in je hosts file staan? Heb je hier ook een IPv6 adres aan hangen? Zoja, dan komt dit hele probleem omdat je geen IPv6 DNS servers in je resolv.conf hebt. IPv4 heeft wel wat om mee te resolven, IPv6 niet en pakt dan je hosts bestand.

Dit probleem is volgens mij al opgelost. Hij heeft een * in z'n domein staan en het progje waar het om gaat (curl?) besluit om een search domein toe te voegen. Onder IPv4 krijg je gewoon antwoord voor wordpress,org, maar onder ipv6 wordt er een fallback gedaan naar wordpress.org.zijn.domijn

edit: even de wildcard voor mijn domain op ipv6 verwijderd en dan werkt het wel goed...Dus blijft de vraag over waarom op ipv6 mijn eigen domain geappend wordt (indien ipv6) en waarom dat op ipv4 niet gebeurd...beetje vaag

Als je nu 'ping abcdef123.nl' doet (een domein dat ook onder IPv4 niet bestaat), wat gebeurd er dan?

[Osiris]

CAPSLOCK2000 schreef op zondag 14 juli 2013 @ 12:59:
[...]


Dit probleem is volgens mij al opgelost. Hij heeft een * in z'n domein staan en het progje waar het om gaat (curl?) besluit om een search domein toe te voegen. Onder IPv4 krijg je gewoon antwoord voor wordpress,org, maar onder ipv6 wordt er een fallback gedaan naar wordpress.org.zijn.domijn

Wel een forse work-around tho. Een AAAA-wildcard zou gewoon mogelijk moeten zijn. Ik zou het geen "oplossing" durven te noemen

[CAPSLOCK2000]

Osiris schreef op zondag 14 juli 2013 @ 13:07:

Wel een forse work-around tho. Een AAAA-wildcard zou gewoon mogelijk moeten zijn. Ik zou het geen "oplossing" durven te noemen

Het is ook mogelijk en het werkt, maar het probleem is dat die wildcard hier een beetje te goed werkt. Het is ook een beetje een stapel van handigheidjes die nu tegen ons werkt.
Zo'n wildcard in je domein is conceptueel niet heel mooi.
Een search-domein is natuurlijk hardstikke handig, maar uiteindelijk minder nauwkeurig dan alles helemaal uittikken.
En dat we uberhaupt nog A-records hebben in plaats van dat iedereen al AAAA gebruikt is natuurlijk ook niet zoals het ooit bedacht is.

Niet dat ik suggereer dat we het anders moeten gaan doen hoor, veranderen is ook niet praktisch. TS had zelf ook al bedacht dat je geen search-domein wil gebruiken als je een ster in je domein hebt. Dat je dat uberhaupt moet weten is al een probleem op zich.

[Osiris]

Nee, die wildcard werkt helemaal niet "te goed".

Er gaat gewoon bepaalde software de mist in door onterecht de search domain te gebruiken in een situatie waarbij dat zowel niet nodig als niet gewenst is. Dat staat IMO compleet los van wildcards en A/AAAA-records.

[Kees]

Osiris schreef op zondag 14 juli 2013 @ 13:50:
Nee, die wildcard werkt helemaal niet "te goed".

Er gaat gewoon bepaalde software de mist in door onterecht de search domain te gebruiken in een situatie waarbij dat zowel niet nodig als niet gewenst is. Dat staat IMO compleet los van wildcards en A/AAAA-records.

Een search domein met een wildcard erin is altijd ongewenst. Dan resolved namelijk alles, en dat wil je niet. En de software gaat helemaal niet onterecht in de fout, want dat is nu juist de bedoeling van een search domein.

Dus twee dingen kun je doen:
- search domein weghalen/vervangen door iets zonder wildcard (met 1 of 2 servers is een search domein sowieso niet echt nuttig)
- wildcard uit de dns halen

[Osiris]

kees, er staat nergens een wildcard in een search domain. (Voor zover ik begrepen heb.) Sterker nog, er staat überhaupt geen search domain ingesteld voor zover de TS weet. Echter een "fake" search domain die niet resolvet "lost" het probleem op. Net als de wildcard in de DNS weghalen het probleem "oplost", omdat het resolven dan ook de mist in gaat. Echter vind ik dat nogal een forse workaround voor iets wat niet voor zou moeten komen?

[ Voor 3% gewijzigd door Osiris op 14-07-2013 14:15 ]

[Hero of Time]

De TS had *.domein.ext in z'n hosts bestand staan. Dat zorgde voor alle problemen. Dit is iets wat je niet wilt, en ook niet moet doen. De reden dat hij dat heeft gedaan zal wel met z'n webserver config te maken hebben, maar werkt alleen maar averechts. Gewoon domein.ext in je hosts is genoeg. Geen wilcard nodig.

[Osiris]

Hero of Time schreef op zondag 14 juli 2013 @ 14:48:
De TS had *.domein.ext in z'n hosts bestand staan. Dat zorgde voor alle problemen. Dit is iets wat je niet wilt, en ook niet moet doen. De reden dat hij dat heeft gedaan zal wel met z'n webserver config te maken hebben, maar werkt alleen maar averechts. Gewoon domein.ext in je hosts is genoeg. Geen wilcard nodig.

Misschien ben ik blind hoor, maar ik hoor alleen jou dingen zeggen over 't hosts-bestand. De TS zie ik 't nergens noemen?

[Hero of Time]

Osiris schreef op zondag 14 juli 2013 @ 15:00:
[...]

Misschien ben ik blind hoor, maar ik hoor alleen jou dingen zeggen over 't hosts-bestand. De TS zie ik 't nergens noemen?

Ik vraag 't aan de TS, vanwege dit:

edit: even de wildcard voor mijn domain op ipv6 verwijderd en dan werkt het wel goed.

Tot de TS mijn vraag beantwoord of hij 't in z'n hosts heeft staan, ga ik er vanuit dat 't zo is.

[Osiris]

Tja, dat is een aanname. En ik gok dat hij 't over z'n DNS-server (waar die ook gehost wordt) heeft. Interessant dat je een eigen aaname meteen als waarheid aanneemt

Ah, z'n domeintje staat bij NXS Ik gok dat de kans 't grootst is dat de wildcard zich daar bevond, maar dat kan ik nu natuurlijk niet meer bewijzen, aangezien de TS die verwijderd heeft

[ Voor 36% gewijzigd door Osiris op 14-07-2013 15:48 ]

[idef1x]

Hero of Time schreef op zondag 14 juli 2013 @ 15:29:
[...]

Ik vraag 't aan de TS, vanwege dit:

[...]

Tot de TS mijn vraag beantwoord of hij 't in z'n hosts heeft staan, ga ik er vanuit dat 't zo is.

Met de wildcard uit mijn ipv6 halen bedoelde ik op de DNS server (externe partij, dus niet lokaal op de server) en niet in mijn hosts file.

[idef1x]

Osiris schreef op zondag 14 juli 2013 @ 15:46:
Tja, dat is een aanname. En ik gok dat hij 't over z'n DNS-server (waar die ook gehost wordt) heeft. Interessant dat je een eigen aaname meteen als waarheid aanneemt

Ah, z'n domeintje staat bij NXS Ik gok dat de kans 't grootst is dat de wildcard zich daar bevond, maar dat kan ik nu natuurlijk niet meer bewijzen, aangezien de TS die verwijderd heeft

Eh ja daar stond de wildcard dus

Maarre zover ik nu het DNS verhaal mbt search path begrijp zou dat search path eigenlijk alleen geappend dienen te worden indien het aantal dots minder is dan 1 (default). Ik kan niet vinden of het op die server anders dan de default is, maar klinkt logisch dat je alleen gaat appenden bij resolving naar hostsnamen zonder domein extensie, zoals bijvoorbeeld resolving naar "mail" naar mail.mijn.domain zou moeten gaan resolven, maar "mail.nl" gewoon naar mail.nl.

de Apache webserver draait overigens op ipv4 en ipv6.
Ik blijf het nog steeds vaag vinden waarom het bij ipv4 dus wel goed gaat, want dat zou dezelfde procedure moeten volgen.

Zoals eerder al gemeld: een ping op ikbestanietdomein.nl geeft unknown host en een ping6 op ikbestanietdomein.nl resolved naar het lokale ipv6 global address (zoals de wildcard in mijn domein staat) en geeft dus response.
m.a.w. ipv6 resolving != ipv4 resolving??

M.i. moet die wildcard (catchall) gewoon moeten kunnen, anders hadden ze hem niet bedacht lijkt me. Is ook wel makkelijk als je even een nieuwe site online wil brengen, dan hoef je DNS niet aan te passen. Niet dat het veel moeite is, maar toch...

[Kees]

Over die ndots, daar moet je de manpage goed voor lezen:

ndots:n
sets a threshold for the number of dots which must appear in a name given to res_query(3) (see resolver(3)) before an initial absolute query will be made. The
default for n is 1, meaning that if there are any dots in a name, the name will be tried first as an absolute name before any search list elements are appended to
it. The value for this option is silently capped to 15.

Dus als je die op 1 zet, dan zal hij eerst de naam zelf proberen te resolven, maar als dat niet lukt, dan voegt hij het searchdomein toe.
Voorbeeld:

$ host -v test.testing.tester 
Trying "test.testing.tester"
Received 37 bytes from 127.0.0.1#53 in 0 ms
Trying "test.testing.tester.tweakers.net"
Host test.testing.tester not found: 3(NXDOMAIN)
Received 50 bytes from 127.0.0.1#53 in 0 ms

$ host -v test
Trying "test.tweakers.net"
Trying "test"
Host test not found: 3(NXDOMAIN)
Received 97 bytes from 127.0.0.1#53 in 2 ms

Als er dots instaan dan probeert hij het met die naam en als dat niet lukt => searchdomein erachter. Als je iets zonder dots opgeeft dan probeert hij het meteen met de searchdomein erachter

[Osiris]

Ja, dat snappen we kees. We snappen alleen niet waarom de bak van de TS doet alsof 'ie voor IPv4 ndots op 1 (default) heeft staan en voor IPv6 op 2 (of misschien zelfs wel hoger?)

@TS: Wat doet ping6 www.wordpress.org e.d.? Of bla.bla.bla.bla.invalid? Houdt 'ie überhaupt op met resolven met je eigen search-domain? Werkt IPv6 resolven überhaupt? (ping6 www.google.com oid)

[idef1x]

Ja ping6 op www.google.com doet het bijvoorbeeld wel:

code:

 PING www.google.com(2a00:1450:400c:c03::6a) 56 data bytes
64 bytes from 2a00:1450:400c:c03::6a: icmp_seq=1 ttl=56 time=6.22 ms
64 bytes from 2a00:1450:400c:c03::6a: icmp_seq=2 ttl=56 time=6.10 ms
^C
--- www.google.com ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1000ms
rtt min/avg/max/mdev = 6.101/6.162/6.223/0.061 ms

ping6 www.wordpress.org geeft unknown host terug dus dat werkt goed

Hmm interessant ipv4:

code:

 ping -n bla.bla.bla.invalid.domain.nl.invalid
PING bla.bla.bla.invalid.domain.nl.invalid.sjomar.eu (91.213.195.211) 56(84) bytes of data.
64 bytes from 91.213.195.211: icmp_req=1 ttl=64 time=0.019 ms
64 bytes from 91.213.195.211: icmp_req=2 ttl=64 time=0.060 ms
^C
--- bla.bla.bla.invalid.domain.nl.invalid.sjomar.eu ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 999ms
rtt min/avg/max/mdev = 0.019/0.039/0.060/0.021 ms

en ipv6:

code:

ping6 -n bla.bla.bla.invalid.domain.nl.invalid
PING bla.bla.bla.invalid.domain.nl.invalid(2a02:2770:3:0:21a:4aff:fe0f:635f) 56 data bytes
64 bytes from 2a02:2770:3:0:21a:4aff:fe0f:635f: icmp_seq=1 ttl=64 time=0.021 ms
64 bytes from 2a02:2770:3:0:21a:4aff:fe0f:635f: icmp_seq=2 ttl=64 time=0.044 ms
^C
--- bla.bla.bla.invalid.domain.nl.invalid ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1000ms
rtt min/avg/max/mdev = 0.021/0.032/0.044/0.012 ms

de replies komen van het lokale ipv4 en ipv6 respectievelijk

en voor wordpress.org ipv4:

code:

ping -n wordpress.org
PING wordpress.org (66.155.40.250) 56(84) bytes of data.
64 bytes from 66.155.40.250: icmp_req=1 ttl=51 time=175 ms
64 bytes from 66.155.40.250: icmp_req=2 ttl=51 time=175 ms
^C
--- wordpress.org ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1000ms
rtt min/avg/max/mdev = 175.555/175.559/175.564/0.419 ms

en voor ipv6:

code:

 ping6 -n wordpress.org
PING wordpress.org(2a02:2770:3:0:21a:4aff:fe0f:635f) 56 data bytes
64 bytes from 2a02:2770:3:0:21a:4aff:fe0f:635f: icmp_seq=1 ttl=64 time=0.018 ms
64 bytes from 2a02:2770:3:0:21a:4aff:fe0f:635f: icmp_seq=2 ttl=64 time=0.063 ms
^C
--- wordpress.org ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 999ms
rtt min/avg/max/mdev = 0.018/0.040/0.063/0.023 ms

ipv4 reply van de juiste en ipv6 van lokaal

schiet mij maar lek

NB: wildcard staat weer aan

[ Voor 0% gewijzigd door idef1x op 17-07-2013 14:57 . Reden: wildcard weer aan ]

[Osiris]

Ik heb 't idee dat jouw bak sowieso 't search domain gebruikt indien er geen A- of AAAA-record gevonden wordt..

Da's dus los van ndots. Immers: ndots is vóór een eventuele DNS-query richting de DNS-server. Ik denk dat jouw bak éérst een wordpress.com IN AAAA-query richting de DNS-server stuurt en vervolgens (aangezien die geen IP teruggeeft) als backup je search domain pakt. (Wat IMO achterlijk is..)

Maar dat gedrag zou je dus in je tcpdump/WireShark terug moeten kunnen vinden. Eérst een DNS-query voor wordpress.com IN AAAA en dáárna die met je search domain.

[ Voor 16% gewijzigd door Osiris op 17-07-2013 15:04 ]

[idef1x]

Dat klopt als een bus. eerst een AAAA query en dan met mijn domein erachter nog eens een AAAA query.
Maar inderdaad achterlijk en waarom doet ie dat? is dat normaal voor Ubuntu 12.04?? Ik weet dat ze sinds deze versie resolving op de schop hebben gegooid, maar dit is gewoon achterlijk en lijkt me niet te kloppen..belast de DNS ook onnodig...Misschien die Fransoos? eens in zijn blog indertijd erover spammen dan maar. (hmmm zijn site lijkt nu plat te liggen: http://www.stgraber.org/2012/02/24/dns-in-ubuntu-12-04/ )...Die leek het wel te snappen hoe het werkt/zou moeten werken

Afijn ik haal de wildcard maar weer weg voorlopig.

[deadinspace]

Waarom dit gebeurt is vrij simpel. Als er een search domain is ingesteld, dan probeert de resolver eerst de hostname zo te resolven (mits het aantal dots minstens ndots is). Als dat faalt, dan probeert de resolver het nogmaals, maar dan met het search domain er achter geplakt.

wordpress.org resolven voor IPv4 levert dus 66.155.40.{249,250} op (de directe poging werkt).
wordpress.org resolven voor IPv6 faalt (want geen AAAA record), dus probeert de resolver het nogmaals maar dan met wordpress.org.sjomar.eu. Die query matcht je wildcard record en resolved dus naar het IPv6 adres van je server. Om dezelfde reden pingt bla.invalid je eigen server (over zowel v4 als v6).

De enige vraag is dan waarom sjomar.eu je search domain is. Waarschijnlijk heb je "domain sjomar.eu" in /etc/resolv.conf staan, die optie geldt ook als search domain.

Wat moet je doen om het op te lossen? Je kunt domain search disablen door "domain" uit resolv.conf te halen of hem expliciet te overriden met "search .". Merk op dat /etc/resolv.conf direct aanpassen weinig zin heeft aangezien dat bestand beheerd wordt door resolvconf. Daarvoor moet je in /etc/resolvconf/ zijn (of alternatief in interfaces of dhclient.conf).

Maar wat me een beter idee lijkt: zet je wildcard domain op een subdomein. Ik neem aan dat je je wildcard gebruikt om testsites te maken oid, dus dan is het geen groot bezwaar om *.test.sjomar.eu te gebruiken. En het voorkomt het een en ander aan gezeur

[Osiris]

Nou ja, simpel simpel.. In de TS z'n 3e post geeft hij al aan: "in de /etc/resolv.conf staan alleen de dns servers, dus ergens anders moet dat vast staan iets van search domain of append domain..... (ook niet in /etc/network/interfaces overigens)".

De mogelijkehd om de search domain overriden was inderdaad reeds gevonden. Daar een losse punt voor gebruiken is inderdaad wel een nette oplossing (itt een fake domain in te vullen)

Wat de TS óók nog kan doen is: een subdomeintje met "*.dnssearc.sjomar.eu" aan te maken en een scriptje die een hippe "Helaas, het domein <blaat> kan niet worden gevonden!" met een random lolcats-image eronder output!

[idef1x]

Gelukkig dat Deadinspace het simpel vind Waarom gedraagd het zich dan anders (voor wordpress.org iig) op ipv4 dan op ipv6?

Het search sjomar.eu domein haalde/haald ie overigens van zijn FQDN.

Toch blijf ik het raar vinden dat als ndots > 1 is toch ook met het search domein wordt geresolved. Een onnodige belasting van de DNS in mijn optiek. Ik kan me namelijk geen situatie bedenken dat dat nodig is? Indien wel nodig zou ik zeggen pas je domain search path in je DHCP server settings aan (daar zal het 1e de eventuele "problemen" zich openbaren lijkt me)

Oh en ik denk dat ik het maar laat bij mijn DNS instellen zonder wildcard

[ Voor 6% gewijzigd door idef1x op 17-07-2013 20:51 ]

[Osiris]

idef1x schreef op woensdag 17 juli 2013 @ 20:50:
Waarom gedraagdTTTTT het zich dan anders (voor wordpress.org iig) op ipv4 dan op ipv6?

Omdat wordpress.org wél een A-record, maar géén AAAA-record heeft. Dat had je eerder al ontdekt dat het daar aan lag

idef1x schreef op woensdag 17 juli 2013 @ 20:50:
Oh en ik denk dat ik het maar laat bij mijn DNS instellen zonder wildcard

'k Zou de search-path "." kiezen als ik jou was

[idef1x]

idef1x schreef op woensdag 17 juli 2013 @ 20:50:
Waarom gedraagdTTTTT het zich dan anders (voor wordpress.org iig) op ipv4 dan op ipv6?

Hmm ja verkeerde vraag en goede antwoord Ik bedoelde te vragen waarom ie zich eigenlijk zo gedraagt?
Maar dat is wellicht meer iets voor de mensen die het zo bedacht hebben.
Ik zou het (iig in mijn situatie) logischer vinden als : eerst AAAA request voor de exacte vraag, dan een A request, dan een AAAA met search path en dan als laatste een A record met search path opvragen. Dan nog geen success....-> unknown host. Maar goed er zal wel een reden voor zijn

Als je als search path "." kiest, dan sloop je de hele werking van het search path lijkt me en die zit er ook niet voor niets. Als ik mijn thuisnetwerkje zo bekijk, vind ik het wel handig om alleen de hostnaam in te tikken i.p.v. de fqdn.
Dus ja een search path is wel handig. Voor die vps maakt het inderdaad niet uit.

Bedankt voor je info steeds

[Hero of Time]

idef1x schreef op donderdag 18 juli 2013 @ 09:25:
[...]



Hmm ja verkeerde vraag en goede antwoord Ik bedoelde te vragen waarom ie zich eigenlijk zo gedraagt?
Maar dat is wellicht meer iets voor de mensen die het zo bedacht hebben.
Ik zou het (iig in mijn situatie) logischer vinden als : eerst AAAA request voor de exacte vraag, dan een A request, dan een AAAA met search path en dan als laatste een A record met search path opvragen. Dan nog geen success....-> unknown host. Maar goed er zal wel een reden voor zijn

Dat het zo gedraagt komt door de manier hoe IP is gemaakt. Met de komst van IPv6 zal het systeem IPv6 als voorkeur gebruiken en als je een IPv6 adres hebt, geen fallback doen naar IPv4. Je kan dit wel instellen, maar waar dat precies staat, is applicatieafhankelijk.

Als je als search path "." kiest, dan sloop je de hele werking van het search path lijkt me en die zit er ook niet voor niets. Als ik mijn thuisnetwerkje zo bekijk, vind ik het wel handig om alleen de hostnaam in te tikken i.p.v. de fqdn.
Dus ja een search path is wel handig. Voor die vps maakt het inderdaad niet uit.

Bedankt voor je info steeds

Voor een lokaal thuis netwerkje heb je niet eens een DNS server draaien die al je hostnames registreert, dus daar heb je niets aan. Als je wel een DNS servertje hebt draaien, dan kan je 't resolven ook op een andere, betere manier doen dan met searchdomain.

[idef1x]

Hero of Time schreef op donderdag 18 juli 2013 @ 09:59:
[...]

Dat het zo gedraagt komt door de manier hoe IP is gemaakt. Met de komst van IPv6 zal het systeem IPv6 als voorkeur gebruiken en als je een IPv6 adres hebt, geen fallback doen naar IPv4. Je kan dit wel instellen, maar waar dat precies staat, is applicatieafhankelijk.

Duidelijk

Voor een lokaal thuis netwerkje heb je niet eens een DNS server draaien die al je hostnames registreert, dus daar heb je niets aan. Als je wel een DNS servertje hebt draaien, dan kan je 't resolven ook op een andere, betere manier doen dan met searchdomain.

Eh die heb ik thuis wel ter speling en ter vermaak zeg maar (dhcp update DNS) en dat werkt prima. Maar kennelijk bestaat er iets beters voor lokale resolving...Kun je/wil je me een hint geven? (behalve alles in (/etc/hosts zetten)

[ Voor 0% gewijzigd door idef1x op 18-07-2013 10:12 . Reden: typootje ]

[deadinspace]

Osiris schreef op woensdag 17 juli 2013 @ 17:48:
Nou ja, simpel simpel.. In de TS z'n 3e post geeft hij al aan: "in de /etc/resolv.conf staan alleen de dns servers, dus ergens anders moet dat vast staan iets van search domain of append domain..... (ook niet in /etc/network/interfaces overigens)".

Ahja, dat had ik even over het hoofd gezien. Maar de TS heeft de inhoud van die bestanden niet gegeven, dus het had alsnog gekund dat er "domain sjomar.eu" in stond, waarbij de TS zich niet realiseert dat dat voor domain searches wordt gebruikt. En dan nog, zelfs al staat dat er niet in, dan wordt het wel uit de hostname gehaald, wat alsnog op hetzelfde neerkomt: er is een search domain actief wat problemen oplevert icm wildcard DNS

Wat de TS óók nog kan doen is: een subdomeintje met "*.dnssearc.sjomar.eu" aan te maken en een scriptje die een hippe "Helaas, het domein <blaat> kan niet worden gevonden!" met een random lolcats-image eronder output!

Zoals ik voorstelde bedoel je?

idef1x schreef op woensdag 17 juli 2013 @ 20:50:
Toch blijf ik het raar vinden dat als ndots > 1 is toch ook met het search domein wordt geresolved. Een onnodige belasting van de DNS in mijn optiek. Ik kan me namelijk geen situatie bedenken dat dat nodig is?

Ik wel, wat nou als je meerdere subdomeinen onder je search domain wil? Stel, je hebt example.com, en twee locaties: Amsterdam (adam) en Eindhoven (ehv). Dan kun je gewoon de domeinnamen server003.adam(.example.com) en desktop456.ehv(.example.com) gebruiken. Voor een kleine setup (bijvoorbeeld thuisgebruikers) weinig nuttig, voor grotere setups (bedrijven of scholen bijvoorbeeld) wel nuttig.

Maar het zou inderdaad wel leuk zijn als er een *maximum* op het aantal dots in te stellen was. Meer dan maxdots dots in de naam? Dan geen search. Misschien een leuke feature request (al zijn de developers van dat soort core functionaliteit meestal niet erg feature-happig)...

idef1x schreef op donderdag 18 juli 2013 @ 09:25:
Ik zou het (iig in mijn situatie) logischer vinden als : eerst AAAA request voor de exacte vraag, dan een A request, dan een AAAA met search path en dan als laatste een A record met search path opvragen. Dan nog geen success....-> unknown host. Maar goed er zal wel een reden voor zijn

Dat gaat (helaas? ik vind het ergens ook wel een beetje ondoorzichtig...) niet. De applicatie vraagt "resolve dit eens voor IPv6 voor me?", en als dat niet lukt vraagt de applicatie "ok, resolve het dan maar voor IPv4?". De resolver krijgt dus maar één IPv6-poging binnen, en daarmee moet hij het doen. Dus eerst absoluut en dan met search domain.

Als je als search path "." kiest, dan sloop je de hele werking van het search path lijkt me en die zit er ook niet voor niets. Als ik mijn thuisnetwerkje zo bekijk, vind ik het wel handig om alleen de hostnaam in te tikken i.p.v. de fqdn.

Klopt, ik maak ook veel gebruik van mijn search domain. Dus mijn voorkeur zou het hebben om je wildcard in een subdomein te zetten.

Ik heb me nog een potentiele oplossing bedacht trouwens: je zou natuurlijk de search domain een subdomein kunnen maken. Dus "search blaat.sjomar.eu.", en dan zorgen dat server.blaat.sjomar.eu naar je server wijst, en dan werkt het ook. Niet de mooiste oplossing, maar ok.

Hero of Time schreef op donderdag 18 juli 2013 @ 09:59:
Voor een lokaal thuis netwerkje heb je niet eens een DNS server draaien die al je hostnames registreert, dus daar heb je niets aan. Als je wel een DNS servertje hebt draaien, dan kan je 't resolven ook op een andere, betere manier doen dan met searchdomain.

Hmm, hoe dan?

[Hero of Time]

deadinspace schreef op donderdag 18 juli 2013 @ 20:44:

[...]

Hmm, hoe dan?

Goede vraag eigenlijk. Op 't werk ben ik zo veel bezig met Windows (bah!) dat ik de optie daar aan dacht. De NIC voegt automatisch 't domein toe aan de hostnaam en zoekt dan enkel in het domein voor hosts met een enkele naam. Zodra er een punt in voor komt, is 't een externe lookup. Heb mij (nog) niet verdiept in het equivalent voor Linux, als dat er al is.

[idef1x]

deadinspace schreef op donderdag 18 juli 2013 @ 20:44:
[...]

Ik wel, wat nou als je meerdere subdomeinen onder je search domain wil? Stel, je hebt example.com, en twee locaties: Amsterdam (adam) en Eindhoven (ehv). Dan kun je gewoon de domeinnamen server003.adam(.example.com) en desktop456.ehv(.example.com) gebruiken. Voor een kleine setup (bijvoorbeeld thuisgebruikers) weinig nuttig, voor grotere setups (bedrijven of scholen bijvoorbeeld) wel nuttig.

Hmm goed punt...stom dat ik daar zelf niet aan gedacht heb...okee klinkt dan wel weer logisch geimplementeerd dan
Dank voor de toelichting!

[idef1x]

Hero of Time schreef op donderdag 18 juli 2013 @ 21:23:
[...]

Goede vraag eigenlijk. Op 't werk ben ik zo veel bezig met Windows (bah!) dat ik de optie daar aan dacht. De NIC voegt automatisch 't domein toe aan de hostnaam en zoekt dan enkel in het domein voor hosts met een enkele naam. Zodra er een punt in voor komt, is 't een externe lookup. Heb mij (nog) niet verdiept in het equivalent voor Linux, als dat er al is.

Eh nou kennelijk zit dat er dan al in bij Linux (iig Ubuntu)? Zoals ik boven al schreef haalt ubuntu het search pad uit de fqdn. Deze zou je in principe via dhcp (clients) door kunnen geven (evenals het search pad overigens) en voor static machines wordt de fqdn toch wel volledig ingevuld?
in de /etc/resolv.conf kan/kon je dit overrulen en nu dus in bijvoorbeeld /etc/network/interfaces..

[Hero of Time]

Je kan dit nog steeds in /etc/resolv.conf wijzigen. Het is alleen dat als je resolvconf geïnstalleerd hebt, dat je resolv.conf beheert. Na een wijziging van je interfaces of geplande run ervan zijn je wijzigingen weg. Maak je geen gebruik van resolvconf, dan regelt dhclient dit als je een searchdomain optie meegeeft met je DHCP.


ps, wijzig je laatste post de volgende keer als je iets hebt toe te voegen . Je kan vanuit de Edit/preview ook gewoon anderen quoten.

[idef1x]

Goede tip van dat quoten...wist ik eerlijk gezegd niet
Zo zie je maar: nooit te oud om nog wat te leren

[Hero of Time]

Echt niet? Nooit omlaag gescrold en gedacht "goh, wat doet die quote knop daar?" Grappig.

[idef1x]

Hero of Time schreef op vrijdag 19 juli 2013 @ 11:32:
Echt niet? Nooit omlaag gescrold en gedacht "goh, wat doet die quote knop daar?" Grappig.

Nog niet eerder nodig gevonden om uberhaupt omlaag te scrollen, wanneer ik een reaktie plaatste