Age | Commit message (Collapse) | Author |
|
RFC 6761, 6.3 Domain Name Reservation Considerations for "localhost.":
3. Name resolution APIs and libraries SHOULD recognize localhost
names as special and SHOULD always return the IP loopback address
for address queries and negative responses for all other query
types. Name resolution APIs SHOULD NOT send queries for
localhost names to their configured caching DNS server(s).
This makes sure that the getaddrinfo(3) and gethostbyname(3) family of
functions always return the loopback address and do not send queries
to name servers. This includes "localhost", "localhost." and
everything under ".localhost" and ".localhost.".
For example, a host underneath the .com.ar zone will per default have
a search list of "com.ar.". resolv.conf(5) has a default of "lookup
bind file". Both combined will result in lookups for "localhost" to
not return 127.0.0.1 because localhost.com.ar is registered in DNS.
It has been known for decades that this is a problem, especially for
localhost.
Problem recently spotted by gonzalo@ and debugged by sthen@
Testing sthen, gonzalo
Input & OK phessler, eric, millert
OK sthen, kn, deraadt
|
|
Originally from djm@. OK deraadt@ florian@ bluhm@
|
|
any changes not taken noted on tech, but chiefly here i did not take the
cancelation - cancellation changes;
|
|
Programs assume that a successful call to getaddrinfo(3) validates the
input as "safe", but that's not true. Characters like '$', '`', '\n'
or '*' can traverse the DNS without problems, but have special
meaning, for example a shell.
There is a function res_hnok() already in libc, but it validates if a
string is a host name, which is too strict in practice. For example
foo-.example.com is not a valid host name, but is used on the
Internet.
Posix has this to say:
"The getaddrinfo() function shall translate the name of a service
location (for example, a host name)"
It hints that the input should be a host name, but it does not
restrict it to it.
This introduces a function hnok_lenient() which restricts the input to
getaddrinfo(3) to the set [A-z0-9-_.]. Additionally two consecutive
dots ('.') are not allowed nor can the string start with - or '.'.
glibc introduced a similar restriction years ago, so this should not
cause problems.
It has been known in the DNS community for years, probably decades
that getaddrinfo(3) is too lenient what it accepts, but it has always
been kicked down the road as "not a DNS problem". Unfortunately this
information never made it out of the DNS community and no coordinated
effort happened to have this addressed in operating systems.
David Leadbeater recently demonstrated how ssh(1) and ftp(1) are too
trusting with what getaddrinfo(3) accepts. Both have been fixed
independently of this.
Input deraadt, eric
OK millert, deraadt
|
|
Spotted by krw@
|
|
RES_USE_DNSSEC is implemented by setting the DNSSEC DO bit in outgoing
queries. The resolver is then supposed to set the AD bit in the reply
if it managed to validate the answer through DNSSEC. Useful when the
application doesn't implement validation internally. This scheme
assumes that the validating resolver is trusted and that the
communication channel between the validating resolver and and the client
is secure.
ok eric@ gilles@
|
|
Requested earlier by eric@
|
|
EDNS allows for various DNS extensions, among which UDP DNS packets size
bigger than 512 bytes. The default is still to not advertize anything.
ok eric@
|
|
pack/unpack contexts.
ok krw@ deraadt@
|
|
direction & ok guenther
|
|
Include tweaks suggested by mpi@
ok deraadt@
|
|
the API gets public.
ok deraadt@
|
|
hostnames before returning them to the caller.
ok deraadt@
|
|
ok jca krw ingo
|
|
to prevent collisions with third-party programs.
suggested by sthen@, ok theo@
|
|
|
|
spotted by matthew@
|
|
|
|
ok bluhm@ naddy@ sthen@
|
|
|
|
|
|
The idea is to eventually replace the existing resolver with
something better. Time to start working on it in tree.
ok deraadt@
|