DNS support in SONiC #70
Conversation
venkatmahalingam
requested review from
a-barboza,
bhavini-gada,
mhampasagar,
prvattem and
sameerdell
doc/mgmt/SONiC_DNS_Support.md
Outdated
|
|
||
| With this feature, users will be able to configure DNS servers and source IP using SONiC Click commands and north bound interface (KLISH/REST/gNMI) provided by management framework module using OpenConfig models. | ||
|
|
||
| Also, backend support to handle new config DB table events to populate nameservers in "/etc/resolv.conf" and add iptable rules to change the source IP of the DNS query that is being sent to the DNS server. |
There was a problem hiding this comment.
We'll explore dnsmasq package for setting the source IP instead of iptables.
dnsmasq supports setting the nameserver as well so we dont need to update "/etc/resolv.conf" file also, looks like co-existence of DHCP is supported for DNS with dnsmasq.
There was a problem hiding this comment.
dnsmasq does not work for loopback interface and hence adding this package to SONiC is not required at this point, also, this enforces to start the dnsmasq service in mgmt VRF explicitly for name resolution in mgmt VRF.
doc/mgmt/SONiC_DNS_Support.md
Outdated
| # 2 Functionality | ||
|
|
||
| ## 2.1 Target Deployment Use Cases | ||
| Manage/configure Management VRF via gNMI, REST and CLI interfaces |
There was a problem hiding this comment.
Is this a typo here. We are not handling Management VRF configurations here right?
There was a problem hiding this comment.
will fix it.
doc/mgmt/SONiC_DNS_Support.md
Outdated
| Manage/configure Management VRF via gNMI, REST and CLI interfaces | ||
|
|
||
| ## 2.2 Functional Description | ||
| Provide CLI, gNMI and REST supports for Management VRF handling |
There was a problem hiding this comment.
Not sure if this correct. We are not enhancing the support for Management VRF or is this related to DNS functionality.
There was a problem hiding this comment.
will fix it.
doc/mgmt/SONiC_DNS_Support.md
Outdated
| | | +--rw server* [address] | ||
| | | +--rw address -> ../config/address | ||
| | | +--rw config | ||
| + | | | +--rw address? oc-inet:ip-address |
There was a problem hiding this comment.
This attribute "address" is already present in the Openconfig yang model:
http://ops.openconfig.net/branches/models/master/openconfig-system.html
There was a problem hiding this comment.
yes, added "+" to mention what fields we support for DNS support.
There was a problem hiding this comment.
will mention it explicitly, since + is confusing.
doc/mgmt/SONiC_DNS_Support.md
Outdated
| + | | | +--rw address? oc-inet:ip-address | ||
| | | | +--rw port? oc-inet:port-number | ||
| | | +--ro state | ||
| + | | +--ro address? oc-inet:ip-address |
There was a problem hiding this comment.
This attribute "address" is already present in the Openconfig yang model:
http://ops.openconfig.net/branches/models/master/openconfig-system.html
doc/mgmt/SONiC_DNS_Support.md
Outdated
|
|
||
| DNS stands for Domain Name System. It is used to translate human readable domain names into machine readable IP addresses. | ||
|
|
||
| With this feature, users will be able to configure DNS servers and source IP using SONiC Click commands and north bound interface (KLISH/REST/gNMI) provided by management framework module using OpenConfig models. |
There was a problem hiding this comment.
Is the source-ip bound to any interface like a loopback interface, in other words, is this a routable address?
There was a problem hiding this comment.
yes, it has to be a routable address.
doc/mgmt/SONiC_DNS_Support.md
Outdated
| ##### 3.6.2.1.1 Configure DNS server & source IP | ||
| ``` | ||
| sonic(config)# ip name-server | ||
| source-ip Configure source IP to reach the name server |
There was a problem hiding this comment.
Please rephrase this to "Configure Source IP, used for the DNS query"
doc/mgmt/SONiC_DNS_Support.md
Outdated
|
|
||
| sonic(config)# no ip name-server 2001:aa:aa::a | ||
|
|
||
| sonic(config)# no ip name-server source-ip 1.1.1.1 |
There was a problem hiding this comment.
If source-ip config is mandatory, we should mention it in this document. Also is there a configuration order between name-server and source-ip (both add & delete)
There was a problem hiding this comment.
source IP is not mandatory, no, we dont have any order restriction.
|
|
||
| With this feature, users will be able to configure DNS servers and source interface using SONiC Click commands and north bound interface (KLISH/REST/gNMI) provided by management framework module using OpenConfig models. | ||
|
|
||
| Also, backend support to handle new config DB table events to populate nameservers in "/etc/resolv.conf" and add iptable rules to change the source IP (present on the source interface) of the DNS query that is being sent to the DNS server. |
There was a problem hiding this comment.
What happens if there are multiple ip addresses configured on the source-interface? What is the rule to resolve which one to pick ?
There was a problem hiding this comment.
Do we take the primary address? Can we distinguish the IP alias from the main address of the interface to use? What is the difference between source-interface and source-address? Are we supporting both?
There was a problem hiding this comment.
We dont have any flag to indicate primary address in the config-DB interface tables, it's hard to get the primary address from config-DB table unless we go directly read the IP address with flag from kernel (but there can be many primary addresses, see below kernel output), for now, we can add the caveat that when there are more than one IP addresses on the interface, we pick the address based on first IP address that we get in the table read, so having only one IPv4/IPv6 address on source interface is recommended in order to make the behavior deterministic. We support only source-interface now not source-IP any more as per PLM' ask.
root@sonic:~# ip address show Ethernet0
20: Ethernet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9100 qdisc pfifo_fast state UP group default qlen 1000
link/ether 90:b1:1c:f4:9d:50 brd ff:ff:ff:ff:ff:ff
inet 21.0.0.1/16 scope global Ethernet0
valid_lft forever preferred_lft forever
inet 22.0.0.1/16 scope global Ethernet0
valid_lft forever preferred_lft forever
inet 20.0.0.2/16 scope global secondary Ethernet0
valid_lft forever preferred_lft forever
inet 21.0.0.2/16 scope global secondary Ethernet0
valid_lft forever preferred_lft forever
inet 22.0.0.2/16 scope global secondary Ethernet0
valid_lft forever preferred_lft forever
inet6 2001::1/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::92b1:1cff:fef4:9d50/64 scope link flags 4000
valid_lft forever preferred_lft forever
root@sonic:~# redis-cli -n 4 keys "INTERFACE*"
1) "INTERFACE|Ethernet0|2001::1/64"
2) "INTERFACE|Ethernet0|21.0.0.2/16"
3) "INTERFACE|Ethernet0|21.0.0.1/16"
4) "INTERFACE|Ethernet0|20.0.0.2/16"
5) "INTERFACE|Ethernet0|22.0.0.1/16"
6) "INTERFACE|Ethernet0|20.0.0.1/16"
7) "INTERFACE|Ethernet0"
8) "INTERFACE|Ethernet0|22.0.0.2/16"
root@sonic:~#
There was a problem hiding this comment.
Yes, please document, since the order of retrieval from the redis-db is redis dependent, and can change between reboot/restart, or in the same session.
Also, what happens if both source-interface and source-ip are configured ? Seems like overkill, since we are recommending that only one ip address be on the interface. Additionally the openconfig-system.yang already has a definition for ntp-source-address? Why to define another way to set the ntp source where it is not even deterministic assignment of ip address?
There was a problem hiding this comment.
We discussed this with PLM, interface name is preferred over IP address to avoid any IP config errors, we dont support source-IP configuration.
| | Verify max DNS servers | Verify more than 6 servers are not allowed | | ||
| | Configure DNS source interface | Verify source interface is present in the DNS table (configDB) and DNS query packets are transmitted with the source IP present in source interface | | ||
| | Delete DNS source interface | Verify source interface is not present in the DNS table (configDB) and DNS query packets are not transmitted with the source IP present in source interface | | ||
| | Configure mgmt VRF | Verify that DNS query packets (from mgmt VRF) are transmitted based on nameservers present in resolv.conf file | |
There was a problem hiding this comment.
When the mgmt-VRF is enabled, should not all DNS queries be resolved using Management VRF only? What is the meaning of configure mgmt-VRF ? How does the application tell the DNS to use Management VRF ?
There was a problem hiding this comment.
whichever IP comes first from the table based on source-intf match will be chosen.
There was a problem hiding this comment.
Looks like this was a reply to the previous question. So the question about Mgmt VRF still stands. Is the Management VRF being supported for DNS queries? Seems like there was some review comments earlier about Management VRF not being supported earlier?
There was a problem hiding this comment.
Yes, DNS on mgmt VRF is supported, no special handling is required, any traffic originating from mgmt VRF refers the "/etc/resolv.conf" for name resolution.
There was a problem hiding this comment.
So, is the "DNS on mgmt VRF" referring to which VRF the DNS server should be looked up in? Or is it referring to listening for local client DNS queries on the loopback interface of a particular VRF ? ("lo" -- default VRF vs "lo-m" -- Mgmt VRF ?) It is confusing what is the intent of the mgmt-VRF support for DNS. Can you please clarify?
There was a problem hiding this comment.
Irrespective of where (default VRF or mgmt VRF) we originate the request (e.g ping with domain name), name resolution refers the file "/etc/resolv.conf" file to get the name server IP to send the DNS queries, there seems to be no service running for name resolution, the name resolution is expected to happen by default with POSIX APIs.
There was a problem hiding this comment.
Are the POSIX apis VRF aware ? If they are not VRF aware, then we cannot claim Management VRF support. It looks like DNS is not supported when Management VRF is enabled. Can you confirm this point ? Unless the application which is making the POSIX api has somehow constrained the api (outside of the api) to use Management VRF, it will not be able to use Management VRF. Is this reasoning correct?
There was a problem hiding this comment.
Yes, looks like it's working with current cgcreate method for IP services in mgmt VRF, we tested the name resolution in mgmt VRF for the ping. please see below for more information, are you referring to something else?
root@sonic:~# cgexec -g l3mdev:mgmt bash
root@sonic:~# ping www.yahoo.com
PING new-fp-shed.wg1.b.yahoo.com (98.138.219.232) 56(84) bytes of data.
64 bytes from media-router-fp2.prod1.media.vip.ne1.yahoo.com (98.138.219.232): icmp_seq=1 ttl=52 time=39.5 ms
64 bytes from media-router-fp2.prod1.media.vip.ne1.yahoo.com (98.138.219.232): icmp_seq=2 ttl=52 time=39.2 ms
^C
--- new-fp-shed.wg1.b.yahoo.com ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 39.258/39.396/39.535/0.242 ms
root@sonic:~# exit
exit
oot@sonic:~# cgexec -g l3mdev:mgmt ping www.google.com
PING www.google.com (172.217.164.100) 56(84) bytes of data.
64 bytes from sfo03s18-in-f4.1e100.net (172.217.164.100): icmp_seq=1 ttl=53 time=3.06 ms
64 bytes from sfo03s18-in-f4.1e100.net (172.217.164.100): icmp_seq=2 ttl=53 time=2.69 ms
^C
--- www.google.com ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1000ms
rtt min/avg/max/mdev = 2.696/2.881/3.067/0.193 ms
root@sonic:~#
root@sonic:~# cat /etc/resolv.conf
###############################################################################
#
# /etc/resolv.conf Configuration file for DNS nameserver.
#Set nameserver
nameserver 8.8.8.8
root@sonic:~#
There was a problem hiding this comment.
Yes, the application is constrained using cgexec. This works only for some applications. Other applications like "docker pull" talk to another daemon -- dockerd. So they would not work in those cases. Yes, cgexec is limiting the application scope (in this case ping scope) to use l3mdev:mgmt -- Management VRF
There was a problem hiding this comment.
docker pull doesnt work well with current mgmt VRF implementation with cgcreate, if we go with the workaround we have to allow default table lookup as a last resort from default VRF, DNS loookup will work fine in that case as well, hope we have covered all cases.
root@sonic:~# cgexec -g l3mdev:mgmt ping www.google.com
PING www.google.com (172.217.164.100) 56(84) bytes of data.
64 bytes from sfo03s18-in-f4.1e100.net (172.217.164.100): icmp_seq=1 ttl=53 time=2.97 ms
64 bytes from sfo03s18-in-f4.1e100.net (172.217.164.100): icmp_seq=2 ttl=53 time=2.66 ms
^C
--- www.google.com ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 2.667/2.819/2.972/0.161 ms
root@sonic:~# ping www.google.com
PING www.google.com (172.217.164.100) 56(84) bytes of data.
64 bytes from sfo03s18-in-f4.1e100.net (172.217.164.100): icmp_seq=1 ttl=53 time=3.05 ms
64 bytes from sfo03s18-in-f4.1e100.net (172.217.164.100): icmp_seq=2 ttl=53 time=2.67 ms
64 bytes from sfo03s18-in-f4.1e100.net (172.217.164.100): icmp_seq=3 ttl=53 time=2.68 ms
^C
--- www.google.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 2.675/2.804/3.053/0.181 ms
root@sonic:~#
| +--rw type enumeration ('global') | ||
| +--rw src_intf? union | ||
|
|
||
| ``` |
There was a problem hiding this comment.
From offline comments, I assume there is no plan to support following n upcoming B+ release?
Is there a way to specify the domain name (domain option of resolv.conf)?
Is there a way to specify search list for host-name lookup (search option)?
There was a problem hiding this comment.
Yes, no plan to support these commands for 3.1.
doc/mgmt/SONiC_DNS_Support.md
Outdated
| ``` | ||
| ; DNS configuration attributes global to the system. Only one instance of the table exists in the system. | ||
| ; Key | ||
| global_key = “global” ; TACACS+ global configuration |
There was a problem hiding this comment.
Looks like a typo over here "TACACS+" ?
There was a problem hiding this comment.
will fix it.
a-barboza
requested review from
rajendra-dendukuri,
suresh-rupanagudi and
ben-gale
|
|
||
| #### 1.1.1.1 add/delete DNS server | ||
| This requirement is to add/delete DNS name server information in the Redis ConfigDB (DNS_SERVER) using Click and mgmt-framework. | ||
| The DNS server can be IPv4/IPv6 ipaddress and multiple DNS name servers can be configured. |
There was a problem hiding this comment.
Is there any limit on number of DNS servers that can be configured
|
|
||
| sonic(config)# ip name-server 2001:aa:aa::a | ||
|
|
||
| sonic(config)# ip name-server source-intf Loopback 0 |
There was a problem hiding this comment.
This mean, all name-server will use the same source-interface. Should take this parameter per server i.e. ip name-server ip-address source-intf Loopback0
| ``` | ||
| sonic# show hosts | ||
| Source Interface : Loopback0 | ||
| Name servers are : 10.11.0.1, 2001:aa:aa::a |
There was a problem hiding this comment.
Please change "Name servers are" to "Name servers". Helping verbs are not used in the show outputs
DNS support in SONiC