Re: RHEL, Centos, Fedora rpm 9.14.6

[Victoria Risk]

> On Sep 30, 2019, at 7:08 AM, Lightner, Jeffrey  
> wrote:
> 
> I can't speak for him but will say Carl has been providing these packages and 
> announcing them on this list for quite some time now and it is valuable to 
> those who would like to use later upstream packages on RHEL/CentOS/Fedora.
> 

I would like to add that ISC very much appreciates Carl’s work over the years 
packaging BIND for CentOS users. He has been meticulous about updating his 
packages promptly every time we have a CVE and I expect quite a few users have 
come to rely on his packages. ISC only recently began providing packages.  I 
reached out to Carl at the time we were planning the ISC packages for advice, 
because of his experience. 


> What's the purpose with these builds, what problems do they solve which are 
> unsolvable with upstream ( ISC ) or downstream ( Fedora/RHEL/CentOS
> ) and why announcing you are building it and how long are you intending to 
> supporting those builds ( encase someone decides to use those builds instead 
> of ISC or downstream distribution maintained ones )?

The ISC packages are different from Carl’s CentOS package and the official 
RedHat packages in several ways:
- the ISC packages start from the ISC tarball, and do not incorporate any 
additional downstream RedHat bug fixes.  (I believe Carl’s packages are also 
built this way.)  ISC can’t support the RedHat packages because they have 
different code, and different bugs from the official ISC releases. 
- the ISC packages provide the most up to date BIND versions. The RedHat 
support policy does not allow them to update applications in a stable OS 
branch.  This is why they cherry-pick things to backport, as Jeffrey explained, 
but this approach has its limits. (Carl’s packages are up to date, of course.)
- the ISC packages specifically incorporate the additional dependencies 
required to enable dnstap support. (I don’t know whether Carl’s packages 
incorporate this or not)

ISC also has respect for and a good relationship with the RedHat team that 
maintains BIND in the RedHat distribution. We each have our own user base we 
are responsible for, and we each have different policies about what sort of 
changes we allow in a stable branch. It is a good thing there are several 
distributions to choose from when deciding on a BIND package.


___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: search and ndots support in bind utilities

[m3047]

One more thing: what about disabling search lists? Can't I make a rule 
that "all FQDNs must be specified with a trailing dot (as documented to 
stop the use of search lists)"?


You'd better test that thoroughly. Firefox still doesn't get the TLS host 
header right, and Apache doesn't toss its breakfast anymore, but it ain't 
pretty. Try https://apache.org./ if you don't believe me...




Good luck, and a good tomorrow...

--

Fred Morris




___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: search and ndots support in bind utilities

[Paul Kosinski via bind-users]

Following https://www.icann.org/en/system/files/files/sac-064-en.pdf,
it sounds like modest groups of Internet users (such as informal clubs)
that don't have their own official domain (like "iment.com") are out of
luck if they would like to have local subdomains -- unless they want to
use the quite misleading reserved TLD "test", that is.

It's really too bad that the committee that expanded the space of TLDs
weren't as farsighted as those who allocated the IPv4 addresses to
include non-routable ones for local (intra-LAN) use.

P.S. Note that the domain implied by the PTR lookup result of such a
group's external IP address, although unique, is usually not suitable.
Most can change without notice due to DHCP, and they also tend to be
something unworkable, like "c-66-31-152-1.hsd1.ma.comcast.net.".


On Mon, 30 Sep 2019 09:35:57 -0600
Paul Ebersman  wrote:

> pemensik> I am aware search is a no-no in DNS community. However, is
> pemensik> there any public documentation to this change? Is there RFC
> pemensik> recommending not to use search or how it should be used,
> pemensik> related to today's top level domains?
> 
> pemensik> While I agree it is dangerous, there are still people using
> pemensik> it. I think we should point them at some document,
> pemensik> explaining what are possible dangers. How to use it safe
> pemensik> way or how to avoid using it at all.
> 
> See ICANN SSAC doc 64:
> 
>   
> 
> It goes into detail on why search/suffix lists are a bad idea.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: search and ndots support in bind utilities

[m3047]

The following is not specific to BIND, but concerns the operating 
environment for DNS software. Ebersman in a later post links to a document 
which foreshadows what I'm about to discuss.


On Mon, 30 Sep 2019, Petr Mensik wrote:

[...]
I am aware search is a no-no in DNS community.


That's barely the "other 10%" of it. It reaches as far as cooked Google 
servers (Stucke's still amusing talk from Black Hat some years ago) and 
comes down to a simple: "whose name do you trust?"


I know from experience with the data that in some $VENDOR's streaming 
NXDOMAIN telemetry feed, on any given day, depending which way the wind is 
blowing, that .belkin will be one of the top 10 TLDs. Luckily Cisco bought 
.cisco, so you can see for yourself if your Passive DNS data provider is 
any good by looking for A queries which resolved to 127.0.53.53.


Why does so much DNS traffic show up inadvertently stemmed with .cisco and 
.belkin? Rhetorically speaking, of course.


The DNS is just one naming service which is queried in attempts to resolve 
resource names into actual instances. Others include hosts, LDAP, NIS, you 
get the idea. If you go down the "no search lists" path, then that means 
everywhere, not just the DNS. (This may also be part of the reason for 
inconsistent behavior; earlier this year I personally saw DNS lookups 
suddenly become case sensitive on SuSE Leap when using getaddrinfo().)


What about Active Directory? If your domain can't resolve inside of 
Windows, does it fall back to the DNS?


Resources doesn't include just web sites, CRLs, adverts, tracking beacons. 
It includes database servers, etcd and other resolution / configuration 
services, drives containing executables to, you know, execute...


It doesn't stop with best practices according to the DNS community. Plenty 
of developers will think they know best for their particular situation, so 
you will see them trying various things that will oftentimes result in 
stemming and trying things from your search list. (Guilty as charged, 
during the SuSE episode I coded an option to force the use of dnspython 
for name resolution.)



Prohibitions like "no search lists" do next to nothing. Clever programmers 
will use whatever domain you specify for your hosts as something to 
deconstruct and use for stemming. An (enforced) search list might be 
preferable!


Look at your DNS traffic, particularly NXDOMAIN. (I'd look for stuff 
resolving in typoed / bit flipped domains too.)


Add a domain you own but do not use as the final fallback in your search 
list, and monitor all DNS traffic going to it.


Even resolving stuff may not stop it from leaking (stop resolution 
attempts), because the developer may not trust your answer. I wouldn't do 
that, of course. ;-) But clearly people obsessed with "happy eyeballs" 
don't share my sensibilities.



Good luck, and a good tomorrow...

--

Fred Morris

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: search and ndots support in bind utilities

[Paul Ebersman]

pemensik> I am aware search is a no-no in DNS community. However, is
pemensik> there any public documentation to this change? Is there RFC
pemensik> recommending not to use search or how it should be used,
pemensik> related to today's top level domains?

pemensik> While I agree it is dangerous, there are still people using
pemensik> it. I think we should point them at some document, explaining
pemensik> what are possible dangers. How to use it safe way or how to
pemensik> avoid using it at all.

See ICANN SSAC doc 64:

  

It goes into detail on why search/suffix lists are a bad idea.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

RE: RHEL, Centos, Fedora rpm 9.14.6

[Lightner, Jeffrey]

I can't speak for him but will say Carl has been providing these packages and 
announcing them on this list for quite some time now and it is valuable to 
those who would like to use later upstream packages on RHEL/CentOS/Fedora.

RHEL's model (and therefore CentOS') is to start with a base upstream package 
of BIND (and most other packages) tied to their major release then modify it to 
work with the other packages in that release.   They then backport bug and 
security fixes from later upstream into their base and put extended versioning 
on that package so you'll know both the upstream from which it was initially 
derived and the specific build they later did.   Using the extended versioning 
one can learn specifically what has changed (e.g. what CVEs are addressed).

Despite using RHEL or CentOS some people prefer to roll their own using later 
(or the latest) upstream versions of BIND.   Carl is providing packages to 
allow for that.

CentOS releases are built based on the source code RedHat provides for their 
releases.   CentOS is actually maintained by RedHat as of  couple of years 
back.   RedHat offers paid subscriptions/support for RHEL but not for CentOS.   
There is the Fedora EPEL that offers packages or upstream version higher than 
those shipped with RHEL/CentOS.   The packages in the EPEL are designed to work 
on RHEL/CentOS but are not supported (directly) by RedHat on RHEL.

Fedora is a bleeding edge distro in the RedHat ecosystem.  It is used as a test 
bed for much of what later goes into RHEL.   It is also maintained but by 
RedHat but again there is no paid subscription/support for it.   They do 2 
major releases per year so would often have the latest upstream package.   


-Original Message-
From: bind-users  On Behalf Of Jóhann B. 
Guðmundsson
Sent: Monday, September 30, 2019 7:11 AM
To: bind-users@lists.isc.org
Subject: Re: RHEL, Centos, Fedora rpm 9.14.6

> https://www.five-ten-sg.com/mapper/bind contains links to the source 
> rpms, and build instructions.


Bind is already package and maintained in Fedora [1] and derivatives as well as 
ISC having it's ownspecific copr repo [2] in addition to that.

Copr exist to overcome limitation in RHEL/CentOS as in RHEL/CentOS consumer 
wanting newer release then what's available in RHEL/CentOS while Fedora 
packages residing in copr repo would under normal circumstance only be needed 
to provide early testing of branches not yet suitable for rawhide ( read as 
9.15.x branch of Bind would be made available in copr for Fedora while 9.14.x 
is what should be shipped in $CURRENT Fedora releases ).

Now the fact that the copr repo contains newer release of Bind compared to 
what's currently being shipped in Fedora indicates that there is some friction 
between the Fedora maintainer ( which in this case seems to be a Red Hat 
employee not an upstream ISC maintainer ) and ISC community about maintaining 
Bind in the distribution.

That said removing patches implemented by Red Hat for Fedora or it's derivative 
( RHEL/CentOS etc ) is usually not a smart thing to do and or not working with 
upstream community ( ISC ) to provide and help maintain releases for specific 
platform or downstream distribution in a package repository maintained by ISC 
and it's community ( be it a copr repo or repository hosted under the isc 
domain ) will only cause confusion and frustration of consumers of ISC 
components at the cost of the upstream/downstream community surrounding the 
relevant components.

That said and given that there is no rocket science involved with removing 
patches and building packages I ask...

What's the purpose with these builds, what problems do they solve which are 
unsolvable with upstream ( ISC ) or downstream ( Fedora/RHEL/CentOS
) and why announcing you are building it and how long are you intending to 
supporting those builds ( encase someone decides to use those builds instead of 
ISC or downstream distribution maintained ones )?

Regards

                Jóhann B.

1. https://koji.fedoraproject.org/koji/packageinfo?packageID=314

2. https://copr.fedorainfracloud.org/coprs/isc/

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: RHEL, Centos, Fedora rpm 9.14.6

[Jóhann B . Guðmundsson]

https://www.five-ten-sg.com/mapper/bind contains links to the source
rpms, and build instructions.



Bind is already package and maintained in Fedora [1] and derivatives as 
well as ISC having it's ownspecific copr repo [2] in addition to that.


Copr exist to overcome limitation in RHEL/CentOS as in RHEL/CentOS 
consumer wanting newer release then what's available in RHEL/CentOS 
while Fedora packages residing in copr repo would under normal 
circumstance only be needed to provide early testing of branches not yet 
suitable for rawhide ( read as 9.15.x branch of Bind would be made 
available in copr for Fedora while 9.14.x is what should be shipped in 
$CURRENT Fedora releases ).


Now the fact that the copr repo contains newer release of Bind compared 
to what's currently being shipped in Fedora indicates that there is some 
friction between the Fedora maintainer ( which in this case seems to be 
a Red Hat employee not an upstream ISC maintainer ) and ISC community 
about maintaining Bind in the distribution.


That said removing patches implemented by Red Hat for Fedora or it's 
derivative ( RHEL/CentOS etc ) is usually not a smart thing to do and or 
not working with upstream community ( ISC ) to provide and help maintain 
releases for specific platform or downstream distribution in a package 
repository maintained by ISC and it's community ( be it a copr repo or 
repository hosted under the isc domain ) will only cause confusion and 
frustration of consumers of ISC components at the cost of the 
upstream/downstream community surrounding the relevant components.


That said and given that there is no rocket science involved with 
removing patches and building packages I ask...


What's the purpose with these builds, what problems do they solve which 
are unsolvable with upstream ( ISC ) or downstream ( Fedora/RHEL/CentOS 
) and why announcing you are building it and how long are you intending 
to supporting those builds ( encase someone decides to use those builds 
instead of ISC or downstream distribution maintained ones )?


Regards

               Jóhann B.

1. https://koji.fedoraproject.org/koji/packageinfo?packageID=314

2. https://copr.fedorainfracloud.org/coprs/isc/

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: search and ndots support in bind utilities

[Petr Mensik]

Hi Mark,

I am aware search is a no-no in DNS community. However, is there any
public documentation to this change? Is there RFC recommending not to
use search or how it should be used, related to today's top level domains?

While I agree it is dangerous, there are still people using it. I think
we should point them at some document, explaining what are possible
dangers. How to use it safe way or how to avoid using it at all.

Most important thing is IMO, all libraries in current system should
behave the same way. When I run dig x.y, then ping x.y, I expect it is
always the same target. When search is used now (on Fedora or RHEL), it
might return DIFFERENT target IP. I think this is much more confusing.

Dig protects you, but applications using getaddrinfo() are still
searching both absolute, then relative name if absolute name does not
exist. I think it makes problem MORE dangerous, since your manual
checking using DNS tools does not show requests. But then real
applications using system resolver are more vulnerable. You have
manually verified it is ok using tools, but it is not from applications.
The problem is still there, but HIDDEN from administrator.

Obvious recommendation is to not use search at all. That would work
always the same on any version. I think until glibc resolver is fixed,
tools should behave still the same way. I would like to push change to
glibc resolver, but it seems I am missing good enough arguments.

Regards,
Petr

On 9/27/19 3:31 AM, Mark Andrews wrote:
> Partially qualified names are inherently unsafe.
> 
> Depending on applying the search list after trying the name as fully
> qualified is just plain dangerous as it depends on a NXDOMAIN response
> from a namespace not under your control to reach the service you are
> after.  TLDs get added all the time.
> 
> One could kind of get away with it back when RFC 1535 was written as
> there were only a handful TLDs to worry about colliding with and that
> was manageable.  That time has long past.  This was the time when ndots
> was invented.  Yes, this was a considered decision.
> 
> Searching with partially qualified names with non-default ndots is also
> unsafe, but slightly less so.  You reach internal information / services
> accidentally instead of leaking it to a external party.
> 
> Mark
> 
>> On 26 Sep 2019, at 9:20 pm, Petr Mensik  wrote:
>>
>> Hello,
>>
>> I got bug report [1] about different behavior of nslookup in 9.11
>> version compared to old 9.9 version. At first I thought this issue
>> should be closed right away. But when I digged into changes in BIND, I
>> could not find any reason for given change. It seems to me the effect
>> was not desired. Or not well documented.
>>
>> What changed since 9.10? In 9.9, bind utilities behaved the same way as
>> internal glibc implementation. When there is dots >= ndots in searched
>> name, absolute name is tried first. If it does not exist, domains from
>> search clause are appended and searched as well. Current nslookup
>> behavior is to use ONLY absolute name when dots >= ndots. While I
>> personally consider it better practice, some people still expect
>> original behavior.
>>
>> What is worse, it makes it inconsistent with evaulation by the system
>> (glibc) dns resolver. This way, host some.service can give different
>> results than getent hosts some.service with search openstacklocal.
>>
>> I would like to find evidence or at least opinions, whether this
>> change[2] was intentional and/or what was the reason for it. It seems
>> either bind utils should revert to use search domains after absolute
>> name or system resolver should be fixed to behave the same way as bind
>> utils. But either change requires decision what is the correct way and
>> how it should behave.
>>
>> In case my description of the problem is unclear, let's have an example:
>>
>> $ nslookup -debug -domain="vm" rhel6.8
>> Server:  127.0.0.1
>> Address: 127.0.0.1#53
>>
>> ** server can't find rhel6.8: NXDOMAIN
>>
>> But on BIND 9.9 or with [2] reverted, it gets:
>> $ ./nslookup -debug -domain="vm" rhel6.8
>> Server:  127.0.0.1
>> Address: 127.0.0.1#53
>>
>> Non-authoritative answer:
>> Name:rhel6.8.vm
>> Address: 192.168.122.109
>>
>> Is it bug or feature?
>>
>> Glibc has the same behavior even on new enough versions.
>> Both glibc-2.28-72.el8 and glibc-2.30.9000-7.fc32 can resolve name with
>> dot inside which host or nslookup cannot resolve. I am aware referenced
>> BIND version is quite archaic.
>>
>> Best regards,
>> Petr
>>
>> 1. https://bugzilla.redhat.com/show_bug.cgi?id=1743572
>> 2.
>> https://gitlab.isc.org/isc-projects/bind9/commit/8afea636ab0c07399aa3e2410b2cfbd41099df98
>> -- 
>> Petr Menšík
>> Software Engineer
>> Red Hat, http://www.redhat.com/
>> email: pemen...@redhat.com  PGP: 65C6C973
>> ___
>> Please visit https://lists.isc.org/mailman/listinfo/bind-users to 
>> unsubscribe from this list
>>
>> bind-us