Making the in-kernel DNS resolver handle server lists

Making the in-kernel DNS resolver handle server lists

[David Howells]

Hi Trond, Anna, Steve,

For kAFS, I'm writing something to allow the in-kernel DNS resolver be able to
ask for a server list (eg. the list of VL servers in an AFS cell) and get back
a list of servers and the addresses associated with each server.

This would be requested by passing an "srv=<version>" option in the callout
info.

The payload handed to the kernel currently looks like something assembled from
the data obtained from a bunch of SRV records that have been further looked up
to A or AAAA.

In the kernel it might get parsed to something like:

	struct address {
		union {
			struct sockaddr_in	sin;
			struct sockaddr_in6	sin6;
		};
	};

	struct server {
		unsigned short		port;
		unsigned short		pref;		// From SRV
		unsigned short		weight;		// From SRV
		unsigned char		ipproto;	// IPPROTO_*
		unsigned int		nr_addrs;	// May be 0
		struct address		*addrs;
	};

	struct server_list {
		unsigned int		nr_servers;
		struct server		servers[];
	};

Is this something that NFS or CIFS (or anything else for that matter) could
find useful?

I also have this loading information from a configuration file as a
backup/override of the DNS.  Could that also be useful to NFS/CIFS?

David

Re: Making the in-kernel DNS resolver handle server lists

[Steve French]

Yes - this could be very useful for cifs  (SMB3) in processing DFS
(global namespace) referrals and also in Witness protocol
redirections, as well as some reconnect scenarios (especially when low
in memory when upcalls could be risky)
On Wed, Sep 12, 2018 at 6:11 AM David Howells <dhowells@redhat.com> wrote:
>
> Hi Trond, Anna, Steve,
>
> For kAFS, I'm writing something to allow the in-kernel DNS resolver be able to
> ask for a server list (eg. the list of VL servers in an AFS cell) and get back
> a list of servers and the addresses associated with each server.
>
> This would be requested by passing an "srv=<version>" option in the callout
> info.
>
> The payload handed to the kernel currently looks like something assembled from
> the data obtained from a bunch of SRV records that have been further looked up
> to A or AAAA.
>
> In the kernel it might get parsed to something like:
>
>         struct address {
>                 union {
>                         struct sockaddr_in      sin;
>                         struct sockaddr_in6     sin6;
>                 };
>         };
>
>         struct server {
>                 unsigned short          port;
>                 unsigned short          pref;           // From SRV
>                 unsigned short          weight;         // From SRV
>                 unsigned char           ipproto;        // IPPROTO_*
>                 unsigned int            nr_addrs;       // May be 0
>                 struct address          *addrs;
>         };
>
>         struct server_list {
>                 unsigned int            nr_servers;
>                 struct server           servers[];
>         };
>
> Is this something that NFS or CIFS (or anything else for that matter) could
> find useful?
>
> I also have this loading information from a configuration file as a
> backup/override of the DNS.  Could that also be useful to NFS/CIFS?
>
> David



-- 
Thanks,

Steve

Re: Making the in-kernel DNS resolver handle server lists

[David Howells]

Steve French <smfrench@gmail.com> wrote:

> Yes - this could be very useful for cifs  (SMB3) in processing DFS
> (global namespace) referrals and also in Witness protocol
> redirections, as well as some reconnect scenarios

Would the data format I outlined be sufficient for you?

> (especially when low in memory when upcalls could be risky)

Ummm...  It's still upcalling - but a single upcall to fetch a block of
associated servers and all their addresses.

David

Re: Making the in-kernel DNS resolver handle server lists

[Steve French]

On Wed, Sep 12, 2018 at 4:18 PM David Howells <dhowells@redhat.com> wrote:
>
> Steve French <smfrench@gmail.com> wrote:
>
> > Yes - this could be very useful for cifs  (SMB3) in processing DFS
> > (global namespace) referrals and also in Witness protocol
> > redirections, as well as some reconnect scenarios
>
> Would the data format I outlined be sufficient for you?
>
> > (especially when low in memory when upcalls could be risky)
>
> Ummm...  It's still upcalling - but a single upcall to fetch a block of
> associated servers and all their addresses.

In a reconnect scenario - anything we can do to make it more likely
reconnect works (especially
with all of the failover, clustering and redirections mechanisms in
SMB3 and later) and can
resolve the new host is good ... so yes even if upcall as long as less
likely to hang ... this
is good


-- 
Thanks,

Steve

Re: Making the in-kernel DNS resolver handle server lists

[Aurélien Aptel]

David Howells <dhowells@redhat.com> writes:
> The payload handed to the kernel currently looks like something assembled from
> the data obtained from a bunch of SRV records that have been further looked up
> to A or AAAA.

I was wondering recently if the current kernel API lets you to access
all A/AAAA records in case a same domain uses multiple ones. It seems
not, is this correct?

> In the kernel it might get parsed to something like:
>
> 	struct address {
> 		union {
> 			struct sockaddr_in	sin;
> 			struct sockaddr_in6	sin6;
> 		};
> 	};

You probably want struct sockaddr_storage here.


>
> 	struct server {
> 		unsigned short		port;
> 		unsigned short		pref;		// From SRV
> 		unsigned short		weight;		// From SRV
> 		unsigned char		ipproto;	// IPPROTO_*
> 		unsigned int		nr_addrs;	// May be 0
> 		struct address		*addrs;
> 	};
>
> 	struct server_list {
> 		unsigned int		nr_servers;
> 		struct server		servers[];
> 	};
>
> Is this something that NFS or CIFS (or anything else for that matter) could
> find useful?

That sounds useful indeed. I'm currently thinking about a failover
mechanism for DFS (symbolic links across servers in cifs). The protocol
supports multiple possible targets for the link in case one is down. The
targets are usually using hostnames so with your change we could have a
second layer of failover at the DNS level.

> I also have this loading information from a configuration file as a
> backup/override of the DNS.  Could that also be useful to NFS/CIFS?

Cheers,
-- 
Aurélien Aptel / SUSE Labs Samba Team
GPG: 1839 CB5F 9F5B FB9B AA97  8C99 03C8 A49B 521B D5D3
SUSE Linux GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)

Re: Making the in-kernel DNS resolver handle server lists

[David Howells]

Aurélien Aptel <aaptel@suse.com> wrote:

> > The payload handed to the kernel currently looks like something assembled
> > from the data obtained from a bunch of SRV records that have been further
> > looked up to A or AAAA.
> 
> I was wondering recently if the current kernel API lets you to access
> all A/AAAA records in case a same domain uses multiple ones. It seems
> not, is this correct?

It does permit this.  kAFS currently uses it.  Just don't pass "ipv4" or
"ipv6" in the callout info as those impose restrictions.

David

Re: Making the in-kernel DNS resolver handle server lists

[Steve French]

On Thu, Sep 13, 2018 at 1:39 AM Aurélien Aptel <aaptel@suse.com> wrote:
>
> David Howells <dhowells@redhat.com> writes:
> > Is this something that NFS or CIFS (or anything else for that matter) could
> > find useful?
>
> That sounds useful indeed. I'm currently thinking about a failover
> mechanism for DFS (symbolic links across servers in cifs). The protocol
> supports multiple possible targets for the link in case one is down. The
> targets are usually using hostnames so with your change we could have a
> second layer of failover at the DNS level.
>
> > I also have this loading information from a configuration file as a
> > backup/override of the DNS.  Could that also be useful to NFS/CIFS?
>
> Cheers,
> --
> Aurélien Aptel / SUSE Labs Samba Team

Yes - the idea that Aurelien notes above is VERY important for some
improving some recovery scenarios, and if this helps us get there
faster it will greatly improve reliability of some common user scenarios.



-- 
Thanks,

Steve

Re: Making the in-kernel DNS resolver handle server lists

[David Howells]

Aurélien Aptel <aaptel@suse.com> wrote:

> > 	struct address {
> > 		union {
> > 			struct sockaddr_in	sin;
> > 			struct sockaddr_in6	sin6;
> > 		};
> > 	};
> 
> You probably want struct sockaddr_storage here.

It's actually now:

	struct address {
		u8 family;
		union {
			struct sockaddr_in	sin;
			struct sockaddr_in6	sin6;
		};
	};

And note that this is schematic not actual.  It's not actually a C union.
ipv4 and ipv6 addresses take up different amounts of space in the binary blob.

One of the criteria is that the blob should be as small as possible since it
gets cached by the kernel as is (as the payload of a key) and only gets looked
at when it gets parsed.

David