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

This is a cryptographically signed message in MIME format.

--------------ms060700020204040604010300
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

On 2/7/22 2:31 AM, Marc wrote:
> I am testing a bit with containers and some of them I am giving=20
> multiple networks (just by adding interfaces on different=20
> 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=20
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'=20
> ip address is being used, which results failed connection.

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

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

ACK

> When I ping this container from a vm only on the 192.168.10.x=20
> 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=20
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=20
> selects/prefers the 'routable' ip from a dns lookup?

I've never addressed this at the routing layer.  Though I would expect=20
that the /default/ route (or a destination network route) to suffice to=20
allow fall back.  --  Though there is a chance that the service running=20
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=20
"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=20
reference of Zytrax's website [1] for syntax that I've not used in ~8 yea=
rs.

The idea here is that the DNS server -- BIND (named) in this case --=20
alters the response that it gives to clients based on their source IP=20
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=20
addresses.  Similarly, clients in the 192.168.122.0/24 network are given =

superior 192.168.122.0/24 IP addresses before the inferior=20
192.168.10.0/24 IP addresses.

> Question: is there a standard for applications to handling multiple=20
> returned A records. So if eg. 3 records are returned, all are being=20
> 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.=20
Expecting an application to try double digits of IP addresses is=20
probably unrealistic.  But where is the line of realistic and=20
unrealistic?  That's situationally dependent.  Some ... more=20
questionable quality ... applications have problems with more than one=20
IP.  Some ... even more questionable quality ... applications have=20
problems with any response that's not an IP, thus even a CNAME is a=20
problem for them.

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

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



--=20
Grant. . . .
unix || die


--------------ms060700020204040604010300
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC
CzowggUiMIIECqADAgECAhEAn5X6cf7kRk2GDx9LLhnqAzANBgkqhkiG9w0BAQsFADCBljEL
MAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs
Zm9yZDEYMBYGA1UEChMPU2VjdGlnbyBMaW1pdGVkMT4wPAYDVQQDEzVTZWN0aWdvIFJTQSBD
bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0yMTExMTUwMDAw
MDBaFw0yMjExMTUyMzU5NTlaMCsxKTAnBgkqhkiG9w0BCQEWGmd0YXlsb3JAdG5ldGNvbnN1
bHRpbmcubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzOnBjTJUlBTzN81c
PlYErJc9kEbTI/hXq0NA6ZoG4VM6puYTEXtITANjgX+NRwwHjldESnC8dvh6Mx5ckEk9sWoD
l8Yr/dWhF3s4fGxAX5ziOeuBI/yX7rKJn6DOwclV3C6dyt3zrLB6LOiF4gA+lk/o3EbOwoPh
pW2MqAywy18OIvzfmEXKdya8E/uIP4v/8AHmtakxHfmZ33Krbwh2oia69esRKc7q2i3Jh+ar
Tf3PuZJETd86Sb0Lz1+3zAXcYko2/3G9O9AwtUSDvkx5IUKieG8R4a8HLwuUTBNIsJ0qOdmv
4hUjc3IsP0jN+xebTE4w7PheolE/OStiFshpKQIDAQABo4IB0zCCAc8wHwYDVR0jBBgwFoAU
CcDy/AvalNtf/ivfqJlCz8ngrQAwHQYDVR0OBBYEFPUkNRFsHVlNMgaz3G4kfNa8DU4VMA4G
A1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF
BQcDAjBABgNVHSAEOTA3MDUGDCsGAQQBsjEBAgEBATAlMCMGCCsGAQUFBwIBFhdodHRwczov
L3NlY3RpZ28uY29tL0NQUzBaBgNVHR8EUzBRME+gTaBLhklodHRwOi8vY3JsLnNlY3RpZ28u
Y29tL1NlY3RpZ29SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3Js
MIGKBggrBgEFBQcBAQR+MHwwVQYIKwYBBQUHMAKGSWh0dHA6Ly9jcnQuc2VjdGlnby5jb20v
U2VjdGlnb1JTQUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcnQwIwYI
KwYBBQUHMAGGF2h0dHA6Ly9vY3NwLnNlY3RpZ28uY29tMCUGA1UdEQQeMByBGmd0YXlsb3JA
dG5ldGNvbnN1bHRpbmcubmV0MA0GCSqGSIb3DQEBCwUAA4IBAQB65EAjbqFApDikmHsLmOMk
yj7wi/Byggy8NpXeQjgQOIIIHLY8PZvVxgrmzIJLshfgJQcq6Pp7hzHRrk3v08L7Eq+Q/pOE
b6/6K/wSu13YUFTD6gSRjUr4SdPt00EMhF+uodaGriJyDmM96EHYhoZVZWZ026wApOjw6HMY
LWBAZlAKhjfAgxhcVbi7ClWi3gkr5u5pp6Z7td4tlffs1KY3V82Q0rf8fctfHpoCT3Ahf2lo
ID9Wo4NSMoa6igYek19H4snA7mJLMgx4EAD5F6Q95bpdMEK5+rTJDlghyhyhjBWEcEY56OUg
ocTy+o+jyZOdKtF1CnwNhkcC+CY6rQKdMIIGEDCCA/igAwIBAgIQTZQsENQ74JQJxYEtOisG
TzANBgkqhkiG9w0BAQwFADCBiDELMAkGA1UEBhMCVVMxEzARBgNVBAgTCk5ldyBKZXJzZXkx
FDASBgNVBAcTC0plcnNleSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx
LjAsBgNVBAMTJVVTRVJUcnVzdCBSU0EgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTgx
MTAyMDAwMDAwWhcNMzAxMjMxMjM1OTU5WjCBljELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdy
ZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEYMBYGA1UEChMPU2VjdGlnbyBM
aW1pdGVkMT4wPAYDVQQDEzVTZWN0aWdvIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5k
IFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMo87ZQK
Qf/e+Ua56NY75tqSvysQTqoavIK9viYcKSoq0s2cUIE/bZQu85eoZ9X140qOTKl1HyLTJbaz
Gl6nBEibivHbSuejQkq6uIgymiqvTcTlxZql19szfBxxo0Nm9l79L9S+TZNTEDygNfcXlkHK
RhBhVFHdJDfqB6Mfi/Wlda43zYgo92yZOpCWjj2mz4tudN55/yE1+XvFnz5xsOFbme/SoY9W
Aa39uJORHtbC0x7C7aYivToxuIkEQXaumf05Vcf4RgHs+Yd+mwSTManRy6XcCFJE6k/LHt3n
dD3sA3If/JBz6OX2ZebtQdHnKav7Azf+bAhudg7PkFOTuRMCAwEAAaOCAWQwggFgMB8GA1Ud
IwQYMBaAFFN5v1qqK0rPVIDh2JvAnfKyA2bLMB0GA1UdDgQWBBQJwPL8C9qU21/+K9+omULP
yeCtADAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHSUEFjAUBggr
BgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMFAGA1UdHwRJMEcwRaBDoEGG
P2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9VU0VSVHJ1c3RSU0FDZXJ0aWZpY2F0aW9uQXV0
aG9yaXR5LmNybDB2BggrBgEFBQcBAQRqMGgwPwYIKwYBBQUHMAKGM2h0dHA6Ly9jcnQudXNl
cnRydXN0LmNvbS9VU0VSVHJ1c3RSU0FBZGRUcnVzdENBLmNydDAlBggrBgEFBQcwAYYZaHR0
cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkqhkiG9w0BAQwFAAOCAgEAQUR1AKs5whX13o6V
bTJxaIwA3RfXehwQOJDI47G9FzGR87bjgrShfsbMIYdhqpFuSUKzPM1ZVPgNlT+9istp5UQN
RsJiD4KLu+E2f102qxxvM3TEoGg65FWM89YN5yFTvSB5PelcLGnCLwRfCX6iLPvGlh9j30lK
zcT+mLO1NLGWMeK1w+vnKhav2VuQVHwpTf64ZNnXUF8p+5JJpGtkUG/XfdJ5jR3YCq8H0OPZ
kNoVkDQ5CSSF8Co2AOlVEf32VBXglIrHQ3v9AAS0yPo4Xl1FdXqGFe5TcDQSqXh3TbjugGnG
+d9yZX3lB8bwc/Tn2FlIl7tPbDAL4jNdUNA7jGee+tAnTtlZ6bFz+CsWmCIb6j6lDFqkXVsp
+3KyLTZGXq6F2nnBtN4t5jO3ZIj2gpIKHAYNBAWLG2Q2fG7Bt2tPC8BLC9WIM90gbMhAmtMG
quITn/2fORdsNmaV3z/sPKuIn8DvdEhmWVfh0fyYeqxGlTw0RfwhBlakdYYrkDmdWC+XszE1
9GUi8K8plBNKcIvyg2omAdebrMIHiAHAOiczxX/aS5ABRVrNUDcjfvp4hYbDOO6qHcfzy/uY
0fO5ssebmHQREJJA3PpSgdVnLernF6pthJrGkNDPeUI05svqw1o5A2HcNzLOpklhNwZ+4uWY
LcAi14ACHuVvJsmzNicxggQ1MIIEMQIBATCBrDCBljELMAkGA1UEBhMCR0IxGzAZBgNVBAgT
EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEYMBYGA1UEChMPU2VjdGln
byBMaW1pdGVkMT4wPAYDVQQDEzVTZWN0aWdvIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24g
YW5kIFNlY3VyZSBFbWFpbCBDQQIRAJ+V+nH+5EZNhg8fSy4Z6gMwDQYJYIZIAWUDBAIBBQCg
ggJZMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTIyMDIwNzE3
MTMxNVowLwYJKoZIhvcNAQkEMSIEINhwtSPwU45SKOUF1qxWIf7DPUNbk8NNJaEeS9Zg/o1x
MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0D
BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC
ASgwgb0GCSsGAQQBgjcQBDGBrzCBrDCBljELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0
ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEYMBYGA1UEChMPU2VjdGlnbyBMaW1p
dGVkMT4wPAYDVQQDEzVTZWN0aWdvIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNl
Y3VyZSBFbWFpbCBDQQIRAJ+V+nH+5EZNhg8fSy4Z6gMwgb8GCyqGSIb3DQEJEAILMYGvoIGs
MIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQH
EwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28g
UlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAn5X6cf7k
Rk2GDx9LLhnqAzANBgkqhkiG9w0BAQEFAASCAQA+w5I+3pWtIbLK2nJLxDJpOy+aV69XANfg
TFdhYoKq5EAuDTr/MrO9HX4zVXi/iKnBbEuhQd0h/K0JmQAoL6wlbFZYZvbP+PpTa8FtP5Ml
ChgH5GUo8DkKl1aMsSWpSmr3CdcoiAeDTQp/IY8kd/2w3a58fRAfDuZoFWTAsdgd2m9rcQwH
hQi+qwb5obWFztObNTnPx8K1wLMv5is/1ouG57bnfxCsCLjOjq9BuvPgRu7asvc247lqN2Lq
UrMG3SczoEX0iOtFTtV9lFFkpOnNkkgotR94rVWdQ6a/zvX+UhS9oOZiBAbTu8UDXYDMVIj9
i/qvxWNQfQ0DiLq5ln5oAAAAAAAA
--------------ms060700020204040604010300--