skipping not 'usefull' ip addresses of a dns lookup

skipping not 'usefull' ip addresses of a dns lookup

[Marc]

DQpJIGFtIHRlc3RpbmcgYSBiaXQgd2l0aCBjb250YWluZXJzIGFuZCBzb21lIG9mIHRoZW0gSSBh
bSBnaXZpbmcgbXVsdGlwbGUgbmV0d29ya3MgKGp1c3QgYnkgYWRkaW5nIGludGVyZmFjZXMgb24g
ZGlmZmVyZW50IG5ldHdvcmtzKS4gVGhpcyB3YXkgSSBjYW4gdXNlIHRoZSBzcGVjaWZpYyBzZXJ2
aWNlIG9uIGJvdGggbmV0d29ya3MuIFdpdGggc29tZSBhcHBsaWNhdGlvbnMgdGhpcyBzZWVtcyB0
byBnbyBmaW5lLiBXaXRoIG90aGVycyB0aGUgJ3dyb25nJyBpcCBhZGRyZXNzIGlzIGJlaW5nIHVz
ZWQsIHdoaWNoIHJlc3VsdHMgZmFpbGVkIGNvbm5lY3Rpb24uDQoNCkV4YW1wbGU6DQpjb250YWlu
dGVyIEEgaGFzIGV0aDAgMTkyLjE2OC4xMC54LzI0IGFuZCBldGgxIDE5Mi4xNjguMTIyLngvMjQN
Cg0KV2hlbiBJIHBpbmcgdGhpcyBjb250YWluZXIgZnJvbSBhIHZtIG9ubHkgb24gdGhlIDE5Mi4x
NjguMTAueCBuZXR3b3JrLiBUaGUgJ2ZpcnN0JyBwaW5nIGZhaWxzICh3aGVuIDE5Mi4xNjguMTIy
LnggaXMgYmVpbmcgcmVzb2x2ZWQpIHRoZSAybmQgcGluZyBpcyBvayBiZWNhdXNlIGl0IHJlc29s
dmVzIHRoZSAxOTIuMTY4LjEwLnggaXANCg0KDQpRdWVzdGlvbjogaXMgdGhlcmUgc29tZSBzZXR0
aW5nIGluIGxpbnV4IHRoYXQgaXQgYXV0b21hdGljYWxseSBzZWxlY3RzL3ByZWZlcnMgdGhlICdy
b3V0YWJsZScgaXAgZnJvbSBhIGRucyBsb29rdXA/DQoNClF1ZXN0aW9uOiBpcyB0aGVyZSBhIHN0
YW5kYXJkIGZvciBhcHBsaWNhdGlvbnMgdG8gaGFuZGxpbmcgbXVsdGlwbGUgcmV0dXJuZWQgQSBy
ZWNvcmRzLiBTbyBpZiBlZy4gMyByZWNvcmRzIGFyZSByZXR1cm5lZCwgYWxsIGFyZSBiZWluZyB0
ZXN0ZWQgdW50aWwgYSB2YWxpZCBjb25uZWN0aW9uIGhhcyBiZWVuIGZvdW5kPw0KDQoNCg0KDQo

Re: skipping not 'usefull' ip addresses of a dns lookup

[Grant Taylor]

[-- Attachment #1: Type: text/plain, Size: 4193 bytes --]

On 2/7/22 2:31 AM, Marc wrote:
> I am testing a bit with containers and some of them I am giving 
> multiple networks (just by adding interfaces on different 
> networks).

Okay.  I think I understand.

> This way I can use the specific service on both networks.

I take this to mean that services A and B are on net10 while services B 
and C are on net122.  Wherein services A and C are isolated to their own 
network with service B being available on both networks.

> With some applications this seems to go fine. With others the 'wrong' 
> ip address is being used, which results failed connection.

I would expect that the connections eventually connect.  If they don't 
ever connect when they choose the wrong /initial/ address, that seems 
like a bug (in the application) to me.

> Example: containter A has eth0 192.168.10.x/24 and eth1 
> 192.168.122.x/24

ACK

> When I ping this container from a vm only on the 192.168.10.x 
> network. The 'first' ping fails (when 192.168.122.x is being resolved) 
> the 2nd ping is ok because it resolves the 192.168.10.x ip

Are you saying the first invocation of the ping command or the first 
ping (ICMP) echo request packet?  Assuming that you are sending multiple 
packets per command invocation, the former seems problematic to me.  The 
latter falls under into the sub-optimal but likely acceptable category.

> Question: is there some setting in linux that it automatically 
> selects/prefers the 'routable' ip from a dns lookup?

I've never addressed this at the routing layer.  Though I would expect 
that the /default/ route (or a destination network route) to suffice to 
allow fall back.  --  Though there is a chance that the service running 
on 192.168.122.x to refuse to talk to clients on 192.168.10.x/24 network 
for various reasons.  And vice versa for 192.168.122.x/24 network trying 
to talk to 192.168.10.x.

My first attempt at addressing this would be via DNS response ordering.

I believe that the BIND (named) "options {...}" directive to do this is 
"sortlist {...}".  Maybe something like the following:

    options {
       ...
       sortlist {
          192.168.10.0/24; {
             192.168.10.0/24;
             192.168.122.0/24;
             };
          192.168.122.0/24; {
             192.168.122.0/24;
             192.168.10.0/24;
             };
       }
       ...
    }

N.B. This is an untested hypothetical config based on memory and quick 
reference of Zytrax's website [1] for syntax that I've not used in ~8 years.

The idea here is that the DNS server -- BIND (named) in this case -- 
alters the response that it gives to clients based on their source IP 
address.  Thus clients in the 192.168.10.0/24 network are given superior 
192.168.10.0/24 IP addresses before inferior 192.168.122.0/24 IP 
addresses.  Similarly, clients in the 192.168.122.0/24 network are given 
superior 192.168.122.0/24 IP addresses before the inferior 
192.168.10.0/24 IP addresses.

> Question: is there a standard for applications to handling multiple 
> returned A records. So if eg. 3 records are returned, all are being 
> tested until a valid connection has been found?

I don't know.  I would /expect/ that well behaved applications would try 
each of the IP addresses that they are given.  At least within reason. 
Expecting an application to try double digits of IP addresses is 
probably unrealistic.  But where is the line of realistic and 
unrealistic?  That's situationally dependent.  Some ... more 
questionable quality ... applications have problems with more than one 
IP.  Some ... even more questionable quality ... applications have 
problems with any response that's not an IP, thus even a CNAME is a 
problem for them.

[1] DNS BIND9 Query Statements (Zytrax) - 
http://www.zytrax.com/books/dns/ch7/queries.html#sortlist

There may be some routing tricks that can be used to try to address 
this.  But I would /definitely/ start with ... streamlining the 
information that is returned from the DNS server to them.  E.g. avoid 
the problem entirely if possible.



-- 
Grant. . . .
unix || die


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4017 bytes --]

RE: skipping not 'usefull' ip addresses of a dns lookup

[Marc]

PiANCj4gTXkgZmlyc3QgYXR0ZW1wdCBhdCBhZGRyZXNzaW5nIHRoaXMgd291bGQgYmUgdmlhIERO
UyByZXNwb25zZSBvcmRlcmluZy4NCj4gDQo+IEkgYmVsaWV2ZSB0aGF0IHRoZSBCSU5EIChuYW1l
ZCkgIm9wdGlvbnMgey4uLn0iIGRpcmVjdGl2ZSB0byBkbyB0aGlzIGlzDQo+ICJzb3J0bGlzdCB7
Li4ufSIuICBNYXliZSBzb21ldGhpbmcgbGlrZSB0aGUgZm9sbG93aW5nOg0KPiANCj4gICAgIG9w
dGlvbnMgew0KPiAgICAgICAgLi4uDQo+ICAgICAgICBzb3J0bGlzdCB7DQo+ICAgICAgICAgICAx
OTIuMTY4LjEwLjAvMjQ7IHsNCj4gICAgICAgICAgICAgIDE5Mi4xNjguMTAuMC8yNDsNCj4gICAg
ICAgICAgICAgIDE5Mi4xNjguMTIyLjAvMjQ7DQo+ICAgICAgICAgICAgICB9Ow0KPiAgICAgICAg
ICAgMTkyLjE2OC4xMjIuMC8yNDsgew0KPiAgICAgICAgICAgICAgMTkyLjE2OC4xMjIuMC8yNDsN
Cj4gICAgICAgICAgICAgIDE5Mi4xNjguMTAuMC8yNDsNCj4gICAgICAgICAgICAgIH07DQo+ICAg
ICAgICB9DQo+ICAgICAgICAuLi4NCj4gICAgIH0NCj4gDQoNCkdSRUFUIFNPTFVUSU9OIFRoYW5r
cyEgb3IgYmV0dGVyIEdSQU5EIDspIHRoaXMgc29sdmVzIG1vc3Qgb2YgdGhlIGlzc3VlcyBJIHRo
aW5rLg0K

Re: skipping not 'usefull' ip addresses of a dns lookup

[Grant Taylor]

[-- Attachment #1: Type: text/plain, Size: 280 bytes --]

On 2/7/22 12:03 PM, Marc wrote:
> GREAT SOLUTION Thanks! or better GRAND ;) this solves most of the 
> issues I think.

You're welcome.

Good luck.

Note:  I assume that other DNS servers have similar capability as BIND 
(named).



-- 
Grant. . . .
unix || die


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4017 bytes --]

RE: skipping not 'usefull' ip addresses of a dns lookup

[Marc]

SGkgR3JhbnQhIA0KDQo+ID4gSSBhbSB0ZXN0aW5nIGEgYml0IHdpdGggY29udGFpbmVycyBhbmQg
c29tZSBvZiB0aGVtIEkgYW0gZ2l2aW5nDQo+ID4gbXVsdGlwbGUgbmV0d29ya3MgKGp1c3QgYnkg
YWRkaW5nIGludGVyZmFjZXMgb24gZGlmZmVyZW50DQo+ID4gbmV0d29ya3MpLg0KPiANCj4gT2th
eS4gIEkgdGhpbmsgSSB1bmRlcnN0YW5kLg0KPiANCj4gPiBUaGlzIHdheSBJIGNhbiB1c2UgdGhl
IHNwZWNpZmljIHNlcnZpY2Ugb24gYm90aCBuZXR3b3Jrcy4NCj4gDQo+IEkgdGFrZSB0aGlzIHRv
IG1lYW4gdGhhdCBzZXJ2aWNlcyBBIGFuZCBCIGFyZSBvbiBuZXQxMCB3aGlsZSBzZXJ2aWNlcyBC
DQo+IGFuZCBDIGFyZSBvbiBuZXQxMjIuICBXaGVyZWluIHNlcnZpY2VzIEEgYW5kIEMgYXJlIGlz
b2xhdGVkIHRvIHRoZWlyIG93bg0KPiBuZXR3b3JrIHdpdGggc2VydmljZSBCIGJlaW5nIGF2YWls
YWJsZSBvbiBib3RoIG5ldHdvcmtzLg0KPiANCj4gPiBXaXRoIHNvbWUgYXBwbGljYXRpb25zIHRo
aXMgc2VlbXMgdG8gZ28gZmluZS4gV2l0aCBvdGhlcnMgdGhlICd3cm9uZycNCj4gPiBpcCBhZGRy
ZXNzIGlzIGJlaW5nIHVzZWQsIHdoaWNoIHJlc3VsdHMgZmFpbGVkIGNvbm5lY3Rpb24uDQo+IA0K
PiBJIHdvdWxkIGV4cGVjdCB0aGF0IHRoZSBjb25uZWN0aW9ucyBldmVudHVhbGx5IGNvbm5lY3Qu
ICBJZiB0aGV5IGRvbid0DQo+IGV2ZXIgY29ubmVjdCB3aGVuIHRoZXkgY2hvb3NlIHRoZSB3cm9u
ZyAvaW5pdGlhbC8gYWRkcmVzcywgdGhhdCBzZWVtcw0KPiBsaWtlIGEgYnVnIChpbiB0aGUgYXBw
bGljYXRpb24pIHRvIG1lLg0KPiANCj4gPiBFeGFtcGxlOiBjb250YWludGVyIEEgaGFzIGV0aDAg
MTkyLjE2OC4xMC54LzI0IGFuZCBldGgxDQo+ID4gMTkyLjE2OC4xMjIueC8yNA0KPiANCj4gQUNL
DQo+IA0KPiA+IFdoZW4gSSBwaW5nIHRoaXMgY29udGFpbmVyIGZyb20gYSB2bSBvbmx5IG9uIHRo
ZSAxOTIuMTY4LjEwLngNCj4gPiBuZXR3b3JrLiBUaGUgJ2ZpcnN0JyBwaW5nIGZhaWxzICh3aGVu
IDE5Mi4xNjguMTIyLnggaXMgYmVpbmcgcmVzb2x2ZWQpDQo+ID4gdGhlIDJuZCBwaW5nIGlzIG9r
IGJlY2F1c2UgaXQgcmVzb2x2ZXMgdGhlIDE5Mi4xNjguMTAueCBpcA0KPiANCj4gQXJlIHlvdSBz
YXlpbmcgdGhlIGZpcnN0IGludm9jYXRpb24gb2YgdGhlIHBpbmcgY29tbWFuZCBvciB0aGUgZmly
c3QNCj4gcGluZyAoSUNNUCkgZWNobyByZXF1ZXN0IHBhY2tldD8gIEFzc3VtaW5nIHRoYXQgeW91
IGFyZSBzZW5kaW5nIG11bHRpcGxlDQo+IHBhY2tldHMgcGVyIGNvbW1hbmQgaW52b2NhdGlvbiwg
dGhlIGZvcm1lciBzZWVtcyBwcm9ibGVtYXRpYyB0byBtZS4gIFRoZQ0KPiBsYXR0ZXIgZmFsbHMg
dW5kZXIgaW50byB0aGUgc3ViLW9wdGltYWwgYnV0IGxpa2VseSBhY2NlcHRhYmxlIGNhdGVnb3J5
Lg0KPiANCj4gPiBRdWVzdGlvbjogaXMgdGhlcmUgc29tZSBzZXR0aW5nIGluIGxpbnV4IHRoYXQg
aXQgYXV0b21hdGljYWxseQ0KPiA+IHNlbGVjdHMvcHJlZmVycyB0aGUgJ3JvdXRhYmxlJyBpcCBm
cm9tIGEgZG5zIGxvb2t1cD8NCj4gDQo+IEkndmUgbmV2ZXIgYWRkcmVzc2VkIHRoaXMgYXQgdGhl
IHJvdXRpbmcgbGF5ZXIuICBUaG91Z2ggSSB3b3VsZCBleHBlY3QNCj4gdGhhdCB0aGUgL2RlZmF1
bHQvIHJvdXRlIChvciBhIGRlc3RpbmF0aW9uIG5ldHdvcmsgcm91dGUpIHRvIHN1ZmZpY2UgdG8N
Cj4gYWxsb3cgZmFsbCBiYWNrLiAgLS0gIFRob3VnaCB0aGVyZSBpcyBhIGNoYW5jZSB0aGF0IHRo
ZSBzZXJ2aWNlIHJ1bm5pbmcNCj4gb24gMTkyLjE2OC4xMjIueCB0byByZWZ1c2UgdG8gdGFsayB0
byBjbGllbnRzIG9uIDE5Mi4xNjguMTAueC8yNCBuZXR3b3JrDQo+IGZvciB2YXJpb3VzIHJlYXNv
bnMuICBBbmQgdmljZSB2ZXJzYSBmb3IgMTkyLjE2OC4xMjIueC8yNCBuZXR3b3JrIHRyeWluZw0K
PiB0byB0YWxrIHRvIDE5Mi4xNjguMTAueC4NCj4gDQo+IE15IGZpcnN0IGF0dGVtcHQgYXQgYWRk
cmVzc2luZyB0aGlzIHdvdWxkIGJlIHZpYSBETlMgcmVzcG9uc2Ugb3JkZXJpbmcuDQo+IA0KPiBJ
IGJlbGlldmUgdGhhdCB0aGUgQklORCAobmFtZWQpICJvcHRpb25zIHsuLi59IiBkaXJlY3RpdmUg
dG8gZG8gdGhpcyBpcw0KPiAic29ydGxpc3Qgey4uLn0iLiAgTWF5YmUgc29tZXRoaW5nIGxpa2Ug
dGhlIGZvbGxvd2luZzoNCj4gDQo+ICAgICBvcHRpb25zIHsNCj4gICAgICAgIC4uLg0KPiAgICAg
ICAgc29ydGxpc3Qgew0KPiAgICAgICAgICAgMTkyLjE2OC4xMC4wLzI0OyB7DQo+ICAgICAgICAg
ICAgICAxOTIuMTY4LjEwLjAvMjQ7DQo+ICAgICAgICAgICAgICAxOTIuMTY4LjEyMi4wLzI0Ow0K
PiAgICAgICAgICAgICAgfTsNCj4gICAgICAgICAgIDE5Mi4xNjguMTIyLjAvMjQ7IHsNCj4gICAg
ICAgICAgICAgIDE5Mi4xNjguMTIyLjAvMjQ7DQo+ICAgICAgICAgICAgICAxOTIuMTY4LjEwLjAv
MjQ7DQo+ICAgICAgICAgICAgICB9Ow0KPiAgICAgICAgfQ0KPiAgICAgICAgLi4uDQo+ICAgICB9
DQo+IA0KPiBOLkIuIFRoaXMgaXMgYW4gdW50ZXN0ZWQgaHlwb3RoZXRpY2FsIGNvbmZpZyBiYXNl
ZCBvbiBtZW1vcnkgYW5kIHF1aWNrDQo+IHJlZmVyZW5jZSBvZiBaeXRyYXgncyB3ZWJzaXRlIFsx
XSBmb3Igc3ludGF4IHRoYXQgSSd2ZSBub3QgdXNlZCBpbiB+OA0KPiB5ZWFycy4NCj4gDQo+IFRo
ZSBpZGVhIGhlcmUgaXMgdGhhdCB0aGUgRE5TIHNlcnZlciAtLSBCSU5EIChuYW1lZCkgaW4gdGhp
cyBjYXNlIC0tDQo+IGFsdGVycyB0aGUgcmVzcG9uc2UgdGhhdCBpdCBnaXZlcyB0byBjbGllbnRz
IGJhc2VkIG9uIHRoZWlyIHNvdXJjZSBJUA0KPiBhZGRyZXNzLiAgVGh1cyBjbGllbnRzIGluIHRo
ZSAxOTIuMTY4LjEwLjAvMjQgbmV0d29yayBhcmUgZ2l2ZW4gc3VwZXJpb3INCj4gMTkyLjE2OC4x
MC4wLzI0IElQIGFkZHJlc3NlcyBiZWZvcmUgaW5mZXJpb3IgMTkyLjE2OC4xMjIuMC8yNCBJUA0K
PiBhZGRyZXNzZXMuICBTaW1pbGFybHksIGNsaWVudHMgaW4gdGhlIDE5Mi4xNjguMTIyLjAvMjQg
bmV0d29yayBhcmUgZ2l2ZW4NCj4gc3VwZXJpb3IgMTkyLjE2OC4xMjIuMC8yNCBJUCBhZGRyZXNz
ZXMgYmVmb3JlIHRoZSBpbmZlcmlvcg0KPiAxOTIuMTY4LjEwLjAvMjQgSVAgYWRkcmVzc2VzLg0K
PiANCj4gPiBRdWVzdGlvbjogaXMgdGhlcmUgYSBzdGFuZGFyZCBmb3IgYXBwbGljYXRpb25zIHRv
IGhhbmRsaW5nIG11bHRpcGxlDQo+ID4gcmV0dXJuZWQgQSByZWNvcmRzLiBTbyBpZiBlZy4gMyBy
ZWNvcmRzIGFyZSByZXR1cm5lZCwgYWxsIGFyZSBiZWluZw0KPiA+IHRlc3RlZCB1bnRpbCBhIHZh
bGlkIGNvbm5lY3Rpb24gaGFzIGJlZW4gZm91bmQ/DQo+IA0KPiBJIGRvbid0IGtub3cuICBJIHdv
dWxkIC9leHBlY3QvIHRoYXQgd2VsbCBiZWhhdmVkIGFwcGxpY2F0aW9ucyB3b3VsZCB0cnkNCj4g
ZWFjaCBvZiB0aGUgSVAgYWRkcmVzc2VzIHRoYXQgdGhleSBhcmUgZ2l2ZW4uICBBdCBsZWFzdCB3
aXRoaW4gcmVhc29uLg0KPiBFeHBlY3RpbmcgYW4gYXBwbGljYXRpb24gdG8gdHJ5IGRvdWJsZSBk
aWdpdHMgb2YgSVAgYWRkcmVzc2VzIGlzDQo+IHByb2JhYmx5IHVucmVhbGlzdGljLiAgQnV0IHdo
ZXJlIGlzIHRoZSBsaW5lIG9mIHJlYWxpc3RpYyBhbmQNCj4gdW5yZWFsaXN0aWM/ICBUaGF0J3Mg
c2l0dWF0aW9uYWxseSBkZXBlbmRlbnQuICBTb21lIC4uLiBtb3JlDQo+IHF1ZXN0aW9uYWJsZSBx
dWFsaXR5IC4uLiBhcHBsaWNhdGlvbnMgaGF2ZSBwcm9ibGVtcyB3aXRoIG1vcmUgdGhhbiBvbmUN
Cj4gSVAuICBTb21lIC4uLiBldmVuIG1vcmUgcXVlc3Rpb25hYmxlIHF1YWxpdHkgLi4uIGFwcGxp
Y2F0aW9ucyBoYXZlDQo+IHByb2JsZW1zIHdpdGggYW55IHJlc3BvbnNlIHRoYXQncyBub3QgYW4g
SVAsIHRodXMgZXZlbiBhIENOQU1FIGlzIGENCj4gcHJvYmxlbSBmb3IgdGhlbS4NCj4gDQo+IFsx
XSBETlMgQklORDkgUXVlcnkgU3RhdGVtZW50cyAoWnl0cmF4KSAtDQo+IGh0dHA6Ly93d3cuenl0
cmF4LmNvbS9ib29rcy9kbnMvY2g3L3F1ZXJpZXMuaHRtbCNzb3J0bGlzdA0KPiANCj4gVGhlcmUg
bWF5IGJlIHNvbWUgcm91dGluZyB0cmlja3MgdGhhdCBjYW4gYmUgdXNlZCB0byB0cnkgdG8gYWRk
cmVzcw0KPiB0aGlzLiAgQnV0IEkgd291bGQgL2RlZmluaXRlbHkvIHN0YXJ0IHdpdGggLi4uIHN0
cmVhbWxpbmluZyB0aGUNCj4gaW5mb3JtYXRpb24gdGhhdCBpcyByZXR1cm5lZCBmcm9tIHRoZSBE
TlMgc2VydmVyIHRvIHRoZW0uICBFLmcuIGF2b2lkDQo+IHRoZSBwcm9ibGVtIGVudGlyZWx5IGlm
IHBvc3NpYmxlLg0KPiANCj4gDQoNCkkgd2FzIGp1c3QgJ2NsZWFuaW5nIHVwJyBhIGJpdCBhbiB1
YnVudHUgc2VydmVyIGZyb20gdW5uZWNlc3NhcnkgcnVubmluZyBwcm9jZXNzZXMuIE5vdyBJIGhh
dmUgc29tZSBleHRlcm5hbCBhdXRoIHRoYXQgaXMgc29tZXRpbWVzIHNsb3cgZHVlIHRvIHRoZSBm
YWN0IHRoYXQgdGhlIGV4dGVybmFsIGF1dGggaG9zdCBoYXMgdHdvIGlwIGFkZHJlc3NlcyBjb25m
aWd1cmVkLiBPbmUgb2YgdGhvc2UgaXAgYWRkcmVzc2VzIGlzIG5vdCByZWFjaGFibGUgZnJvbSBt
eSB1YnVudHUgc2VydmVyLiANCg0KRG8geW91IGtub3cgaWYgdGhlcmUgaXMgY3VycmVudGx5IHNv
bWV0aGluZyBjbGllbnQgc2lkZSB0aGF0IGFjdGl2ZWx5IGFkZHJlc3NlcyB0aGlzIGlzc3VlIG9m
IGhhdmluZyBhcHBsaWNhdGlvbnMgYXNzaWduZWQgaXAgYWRkcmVzc2VzIG9uIGRpZmZlcmVudCBu
ZXR3b3Jrcz8NCg0KSSBkb24ndCB0aGluayBJIG5vdGljZWQgdGhpcyBiZWhhdmlvdXIgYmVmb3Jl
IG15IGNoYW5nZXMsIGNvdWxkIHRoZXJlIGJlIHNvbWV0aGluZyBzbWFydCBpbiBuZXdvcmttYW5h
Z2VyL3N5c3RlbWQ/IA0KDQo

Re: skipping not 'usefull' ip addresses of a dns lookup

[Grant Taylor]

On 8/25/23 2:24 AM, Marc wrote:
> Hi Grant!

Hi Marc,

Real quickly, not having re-read my previous response and had way too 
much water under the bridge between then and now.

> I was just 'cleaning up' a bit an ubuntu server from unnecessary 
> running processes. Now I have some external auth that is sometimes 
> slow due to the fact that the external auth host has two ip addresses 
> configured. One of those ip addresses is not reachable from my 
> ubuntu server.

The first thing that comes to mind is the "auth" a.k.a. "ident" service 
that runs on TCP port 113.  Though I'd be surprised if you actually had 
an ident daemon running.

Is there a chance that you inadvertently changed incoming and / or 
outgoing firewall config to filtered ident requests / replies and / or 
TCP resets / ICMP unreachable messages therefor?

Lack of response to ident requets can cause a delay in services.  This 
could happen by blocking any of the following:
  - outgoing locally generated requests
  - incoming remotely generated replies
  - incoming TCP reset
  - incoming ICMP unreachable message

  - incoming remotely generated requests
  - outgoing locally generated replies
  - outgoing TCP reset
  - outgoing ICMP unreachable message

> Do you know if there is currently something client side that actively 
> addresses this issue of having applications assigned ip addresses on 
> different networks?

I'm going to need more context.  --  Maybe it's in the part of the 
thread that I've not read recently enough.

I'm trying to get a reply out to you quickly.

> I don't think I noticed this behaviour before my changes, could there 
> be something smart in neworkmanager/systemd?

Any time that you question a network related change impacting services, 
my go to solution is a network sniffer, tcpdump on CLI or Wireshark in 
GUI.  (Sometimes both, capture on remote CLI and analyze locally in GUI.)



-- 
Grant. . . .

Re: skipping not 'usefull' ip addresses of a dns lookup

[Erik Auerswald]

Hi,
On Fri, Aug 25, 2023 at 09:27:22PM -0500, Grant Taylor wrote:
> On 8/25/23 2:24 AM, Marc wrote:
> [...]

Just an aside not pertaining to the original question...

> [...]
> Any time that you question a network related change impacting
> services, my go to solution is a network sniffer, tcpdump on CLI or
> Wireshark in GUI.  (Sometimes both, capture on remote CLI and
> analyze locally in GUI.)

I second that.  Looking at the network traffic often helps to get an idea
what is actually happening.

There is a CLI "version" of Wireshark called "TShark" (tshark).  It is
from the wireshark developers.  It provides more detailed information
than tcpdump, i.e., the Wireshark protocol dissection.  (I usually start
with tcpdump for a first impression.  TShark provides an alternative to
copying a capture file to a system with a GUI.)

Cheers,
Erik

Re: skipping not 'usefull' ip addresses of a dns lookup

[Grant Taylor]

On 8/26/23 5:32 AM, Erik Auerswald wrote:
> There is a CLI "version" of Wireshark called "TShark" (tshark). 
> It is from the wireshark developers.  It provides more detailed 
> information than tcpdump, i.e., the Wireshark protocol dissection. 
> (I usually start with tcpdump for a first impression.  TShark provides 
> an alternative to copying a capture file to a system with a GUI.)

I absolutely agree.

My experience is that most systems I want to capture packets on do have 
tcpdump installed but don't have tshark installed.  Or at least at the 
time I want to do the capture.

As such, I use tcpdump for things on system and occasionally pull 
pcap(ng) files back to my workstation where I use Wireshark with all my 
preferences and local name resolution information.

I have also used Wireshark's remote capability a few times where it can 
use ssh to remotely run tcpdump on a remote system.  That's a very slick 
feature when you take the few minutes to set it up the first time.  -- 
I did this on systems I routinely captured traffic on.  E.g. I 
frequently have my primary workstation pre-configured to ssh into the 
router / firewall and remotely run tcpdump to display in Wireshark 
running on said workstation.



Grant. . . .